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ABSTRACT 


The  objective  of  this  thesis  is  to  conduct  a  thorough  analysis  of  the  documentation 
and  policy  that  currently  exists  within  the  Department  of  Defense  (DoD)  framework. 
There  are  numerous  gaps  within  this  documentation  pertaining  to  Human  Systems 
Integration  (HSI)  in  the  Integrated  Defense  Acquisition,  Technology,  and  Logistics 
(IDAT&L)  Life  Cycle.  The  U.S.  Navy  currently  implements  HSI  at  different  stages 
throughout  the  Life  Cycle,  but  it  lacks  continuity  throughout  the  entire  process.  A 
detailed  analysis  of  the  IDAT&L  framework  can  potentially  aid  in  redefining  how  the 
Navy  should  address  HSI,  by  identifying  areas  where  HSI  policies  and  guidelines  should 
exist,  but  currently  do  not  (i.e.,  gaps),  and  then  proposing  ways  to  close  those  gaps  and 
streamline  the  HSI  process  as  a  whole  throughout  the  Navy.  This  thesis  suggests  a 
potential,  strengthened  framework  for  HSI  in  the  Navy,  based  on  the  information  and 
findings  gathered  from  not  only  the  current  framework,  but  also  current  Navy  policies. 
The  outcome  of  this  thesis  is  to  improve  the  entire  HSI  process  throughout  the  Navy  and 
help  ensure  that  HSI  is  used  effectively  throughout  the  acquisition  process. 
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EXECUTIVE  SUMMARY 


The  objective  of  this  thesis  is  to  conduct  a  thorough  analysis  of  the  documentation 
and  policy  that  currently  exists  within  the  Department  of  Defense  (DoD)  framework. 
There  are  numerous  gaps  within  this  documentation  pertaining  to  Human  Systems 
Integration  (HSI)  in  the  Integrated  Defense  Acquisition,  Technology,  and  Logistics 
(IDAT&L)  Life  Cycle.  The  U.S.  Navy  currently  implements  HSI  at  different  stages 
throughout  the  Life  Cycle,  but  it  lacks  continuity  throughout  the  entire  process.  A 
detailed  analysis  of  the  IDAT&L  framework  can  potentially  aid  in  redefining  how  the 
Navy  should  address  HSI,  identifying  areas  where  HSI  policies  and  guidelines  should 
exist,  but  currently  do  not  (i.e.,  gaps),  and  then  proposing  ways  to  close  those  gaps  and 
streamline  the  HSI  process  as  a  whole  throughout  the  Navy. 

The  acquisition  process  contains  a  thorough  structure  from  the  moment  a  need  for 
the  military  is  identified  to  the  moment  that  the  need  is  retired  and  disposed.  This  process 
guides  the  acquisition  community  through  the  important  steps  to  obtain  a  system  that  will 
meet  the  standards  that  are  required.  Within  each  phase  of  the  Life  Cycle,  the  Program 
Manager  (PM)  is  required  to  meet  these  standards.  Every  member  of  the  acquisition 
team,  from  the  user  to  the  engineer,  knows  what  is  required  during  this  process  of  the 
Life  Cycle. 

HSI  is  a  growing  field  that  requires  complete  immersion  into  the  acquisition 
process.  As  of  yet,  it  has  not  been  fully  integrated  throughout  all  of  the  phases.  In  order  to 
obtain  and  develop  the  best  system  for  the  military,  the  acquisition  community  must  gain 
the  knowledge  of  the  system  and  the  user.  In  order  to  develop  the  system  with  the  user  in 
mind,  the  acquisition  cycle  must  integrate  HSI  throughout  the  entire  process.  The 
integration  of  these  HSI  standards  will  allow  the  PM  and  his/her  team  to  acquire  the  best 
system  to  meet  the  needs  of  the  military. 

The  development  of  a  model  that  would  serve  as  our  baseline  allowed  us  to  do  a 
gap  analysis  on  the  policies  and  documentation  within  the  U.S.  Navy’s  acquisition 
process.  The  gap  analysis  provided  us  with  the  gaps  between  the  HSI  standards  (our 
model)  and  what  the  policies  and  documents  say  is  required.  The  recommendations  are 


XV 


provided  to  gain  knowledge  on  how  the  process  could  be  changed  in  order  to  obtain  the 
best  system  for  the  military.  This  model  was  developed  with  the  U.S.  Navy  as  the  main 
priority,  but  may  also  be  useful  for  the  other  services. 

Based  on  the  comparative  analysis  of  the  current  HSI  policies  and  procedures 
utilized  by  the  Navy,  and  the  gaps  identified  in  the  guidelines  and  policies  reviewed,  this 
thesis  makes  recommendations  for  a  joint  framework  for  a  new  comprehensive  policy 
throughout  the  IDAT&L  Life  Cycle  Management  Process.  These  recommendations 
intend  to  improve  the  efficiency  and  effectiveness  of  the  acquisition  process  and  the 
further  development  of  HSI. 
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I. 


INTRODUCTION 


A.  PURPOSE 

The  objective  of  this  thesis  is  to  analyze  the  documentation  and  policy  that 
currently  exists  within  the  Department  of  Defense  (DoD)  framework  dealing  with  the 
Integrated  Defense  Acquisition,  Technology,  and  Logistics  (IDAT&L)  Life  Cycle 
focusing  specifically  on  how  the  United  States  Navy  addresses  Human  Systems 
Integration  (HSI).  Currently,  the  Navy  implements  HSI  at  different  stages  throughout  the 
Life  Cycle.  An  analysis  of  the  IDAT&L  framework  can  potentially  aid  in  understanding 
how  the  Navy  should  address  HSI,  identifying  areas  where  HSI  policies  and  guidelines 
should  exist,  but  do  not  (i.e.,  gaps),  and  then  proposing  ways  to  close  those  gaps.  This 
thesis  is  a  potential  strengthened  framework  for  the  Navy,  based  on  the  information  and 
knowledge  gathered  from  not  only  the  current  framework,  but  also  from  current  Navy 
policies.  The  objective  of  this  thesis  is  to  improve  the  entire  HSI  process. 

B.  BACKGROUND 

HSI  and  the  Defense  acquisition  process  are  inextricably  linked.  In  order  to 
understand  how  the  Defense  Acquisition  System  works,  it  is  critical  to  understand  its 
structure  and  direction.  The  foundation  of  the  acquisition  process  lies  at  the  roots  of  HSI. 
Without  a  solid  footing  in  one,  the  other  cannot  be  successful.  The  Defense  Acquisition 
System,  by  definition,  is  a 

.  .  .  management  process  by  which  the  Department  of  Defense  acquires 
quality  products  in  a  timely  manner,  at  a  fair  and  responsible  price,  and 
which  satisfies  user  needs  with  measureable  improvements  to  mission 
capability  and  operational  support.  The  Defense  Acquisition  System  exists 
to  manage  the  nation’s  investments  in  technologies,  programs,  and  product 
support  in  such  a  way  so  as  to  achieve  the  National  Security  Strategy  to 
support  not  only  today’s  armed  forces,  but  also  the  next  force  and  future 
forces  beyond  that.  (Naval  Air  Systems  Command  (NAVAIR)  Acquisition 
Guide,  2008,  p.  6) 
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HSI  is  thought  to  be  a  process  of  incorporating  characteristics,  capabilities,  and 
limitations  of  humans  within  the  IDAT&L  decision-making  process.  However,  no  set 
definition  has  been  agreed  on  by  HSI  practioners.  A  leading  pioneer  in  the  field  of  HSI, 
Harold  R.  Booher,  defines  HSI  in  his  book,  Handbook  of  Human  Systems  Integration 
(2003),  as:  .  a  comprehensive  management  and  technical  program  that  focuses  on  the 

integration  of  human  considerations  into  the  systems  acquisition  process”  (p.  5).  The 
DoD  Handbook  on  Human  Engineering  Process  and  Procedures, 
MIL-HDBK-46855A,  defines  HSI  as: 

A  comprehensive  management  and  technical  strategy  to  ensure  that  human 
performance,  the  burden  design  imposes  on  manpower,  personnel,  and 
training  (MPT),  and  safety  and  health  aspects  are  considered  throughout 
system  design  and  development.  HSI  assists  with  the  total  system 
approach  by  focusing  attention  on  the  human  part  of  the  total  system 
equation  and  by  ensuring  that  human-related  considerations  are  integrated 
into  the  system  acquisition  process.  (MIL-HDBK-46855A,  Section  5.1.2, 

1999,  p.  19) 

The  Naval  Postgraduate  School  defines  HSI  as: 

HSI  acknowledges  that  the  human  is  a  critical  component  of  any  complex 
system.  It  is  an  interdisciplinary  approach  that  makes  explicit  the 
underlining  tradeoffs  across  the  HSI  domains,  facilitating  optimization  of 
total  system  performance.  (Miller  &  Shattuck,  2006,  p.  4) 

The  National  Aeronautics  and  Space  Administration  (NASA)  defines  HSI  on  their 
NASA  Ames  HSI  Webpage  as: 

...  an  umbrella  term  for  several  areas  of  ‘human  factors’  research  that 
include  human  performance,  technology  design,  and  human-computer 
interaction.  The  study  of  Human  Systems  Integration  at  NASA  Ames 
Research  Center  focuses  on  the  need  for  safe,  efficient  and  cost-effective 
operations,  maintenance  and  training,  both  in  space,  in  flight  and  on  the 
ground.  (NASA  Ames  HSI  Website,  2009) 

As  can  be  seen  from  the  definitions  above,  HSI  practioners  do  not  agree  on  a 
formal  definition  of  HSI.  Given  the  interdisciplinary  nature  of  this  field,  arriving  on  a  set 
definition  is  imperative  as  a  first  step  in  seeing  a  successful  joint  IDAT&L  framework. 
Ideally,  all  DoD  components  should  understand  and  agree  on  the  definition  of  the  field  in 
which  they  are  required  to  work. 
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Based  on  the  “reality”  that  HSI  practioners  and  DoD-related  agencies  do  not  agree 
on  a  common  definition,  it  is  not  surprising  that  they  do  not  agree  on  common  domains 
within  HSI.  The  seven  domains  of  HSI  are  listed  in  MIL-HDBK-46855A,  the  DoD 
Handbook  on  Human  Engineering  Process  and  Procedures'.  Human  Factors  Engineering, 
Manpower,  Personnel,  Training,  Safety,  Health  Hazards,  and  Human  Survivability 
(1999). 

Department  of  Defense  Instruction  (DoDI)  5000.02,  which  was  revised  in  2008, 

.  .  .  establishes  a  simplified  and  flexible  management  framework  for 
translating  mission  needs  and  technology  opportunities,  based  on 
approved  mission  needs  and  requirements,  into  stable,  affordable,  and  well 
managed  acquisition  programs  that  include  weapon  systems  and 
automated  information  systems.  (DoDI  5000.02,  2008,  p.  1) 

This  instruction  applies  to  all  services  within  the  DoD  and  defines  the  domains  of  HSI  as: 
Manpower,  Personnel,  Training,  Human  Factors  Engineering,  Survivability,  Habitability, 
Environment,  Safety,  and  Occupational  Health  (DoDI  5000.02,  2008).  Although  these 
domains  are  defined  in  the  above  document,  each  service  has  redefined  domains  based  on 
their  mission  requirements.  Table  1  shows  disparities  among  the  services  in  the  HSI 
domains.  Like  a  common  definition,  agreeing  on  domains  is  essential  to  a  successful  joint 
acquisition  strategy. 
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Table  1.  Service  HSI  domains  (After:  Miller  &  Shattuck,  2006) 


NAVY 

ARMY 

AIR  FORCE 

MARINE  CORPS 

NASA 

Manpower 

Manpower 

Manpower 

Manpower 

Manpower 

Personnel 

Personnel 

Personnel 

Personnel 

Personnel 

Training 

Training 

Training 

Training 

Training 

Human  Factors 
Engineering 

Human  Factors 
Engineering 

Human  Factors 
Engineering 

Human  Factors 
Engineering 

Human  Factors/ 
Human  Factors 
Engineering 

Human 

Survivability 

Soldier 

Survivability 

Human 

Survivability 

Human  Survivability 

Survivability 

System  Safety 

System  Safety 

System  Safety 

System  Safety 

System  Safety, 
Environmental 
Safety, 
Occupational 
Safety 

Health  Hazards 

Health  Hazards 

Occupational 
Health  Hazards 

Health  Hazards 

Health,  Medical 
Hazards 

Habitability 

Habitability 

Habitability 

Habitability 

Environment 

HSI  sprang  from  problems  in  implementing  the  IDAT&L  Life  Cycle  Management 


Framework.  Although  the  field  of  human  factors  has  existed  for  decades,  the 
interdisciplinary  field  of  HSI  began  to  emerge  after  a  1981  General  Accounting  Office 
(GAO)  report  attributed  50%  of  all  military  equipment  failures  to  human  error 
(GAO,  1981). 

The  report  confirmed  that  the  effectiveness  of  U.S.  forces  could  be 
significantly  increased  through  improved  weapon  system  design.  Further, 
it  stressed  the  immediate  need  for  the  integration  of  manpower,  personnel, 
and  training  (MPT)  considerations  into  the  acquisition  process.  (Belcher, 

1995,  p.  3) 

The  recognition  of  this  deficiency  led  to  the  birth  of  two  DoD  programs: 
Hardware  Procurement  and  Military  Manpower  (HARDMAN)  for  the  Navy  and  Military 
and  Manpower  Integration  (MANPRINT)  in  the  Army.  These  programs  were  designed  to 
improve  human  performance  and  equipment  reliability,  while  helping  to  weed  out  system 
design  flaws. 

In  December  1988,  the  DoD  published  Directive  5000.53,  entitled  “Manpower, 
Personnel,  Training,  and  Safety  (MPTS)  in  the  Defense  Acquisition  Process.”  This 
document  helped  establish  common  MPTS  criteria  among  all  services,  but  was 
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superseded  soon  after  by  DoDI  5000.2,  “Defense  Acquisition  Management  Policies  and 
Procedures,”  in  February  1991.  This  new  document  “mandated  that  human  considerations 
shall  be  effectively  integrated  into  the  design  effort  for  defense  systems  to  improve  total 
system  performance  and  reduce  ownership  costs”  (DoD  ,  2003,  p.  43). 

Although  the  2003  version  of  DoDI  5000.2  outlined  the  requirement  for  HSI,  the 
method  of  implementation  was  left  to  each  individual  service.  Because  each  service  owns 
“HSI,”  the  term  “Human  Systems  Integration”  gets  thrown  around  quite  often;  however, 
few  individuals  know  how  it  works  and  how  it  should  be  implemented.  With  that  being 
said,  each  service  has  created  a  unique  method  for  implementing  it  within  the  confines  of 
that  service,  but  there  is  still  little  agreement  on  what  HSI  is  and  how  each  service  should 
implement  it  in  the  Acquisition  Framework. 

In  2008,  the  2003  version  of  DoDI  5000.2  was  replaced  with  DoDI  5000.02.  The 
new  2008  version  is  similar  to  the  2003  version,  requiring  the  PM  to  optimize  total 
system  performance  and  minimize  the  Life  Cycle  cost  of  ownership  through  a  “total 
system  approach”  to  acquisition  management.  Government  contractors  know  that  HSI  is 
a  contractual  requirement  that  must  be  completed  during  the  design  and  development 
phases  of  the  acquisition  process  (Integrated  Framework  chart,  2005).  Usually,  HSI  is 
initially  addressed  as  a  program  plan  in  the  Joint  Capabilities  Integration  Development 
System  (JCIDS)  process.  However,  its  importance  extends  beyond  Milestone  B.  After 
Milestone  B,  HSI  builds  the  foundation  of  the  materiel  solution  required  to  be  in  the 
program  plan.  If  a  materiel  solution  is  not  identified  in  JCIDS,  the  Life  Cycle  ends  and 
HSI  is  not  implemented  throughout  the  remainder  of  the  doctrine,  organization,  training, 
materiel,  leadership  and  education,  personnel  and  facilities  (DOTMLPF).  Hence,  DoDI 
5000.02  does  not  address  the  entire  Life  Cycle  in  the  document;  HSI  is  also  not 
addressed,  leaving  little  or  no  consideration  to  the  total  Life  Cycle  cost  of  the  program. 
Current  service  policy  addressing  HSI  is  limited  and  differs  among  the  services.  The 
vague  wording  of  many  of  these  documents  indicates  that  HSI  needs  to  be  done; 
however,  it  does  not  provide  criteria  or  guidelines  for  how  to  conduct  HSI  throughout  the 
Life  Cycle.  This  lack  of  information  is  why  it  is  important  that  a  comprehensive  joint 
acquisition  policy,  which  addresses  HSI  throughout  the  Life  Cycle,  be  created  and 
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implemented.  This  thesis  makes  recommendations  for  a  joint  framework  for  a  new 
comprehensive  policy  throughout  the  IDAT&L  Life  Cycle  Management  Process. 


C.  RESEARCH  OBJECTIVES 

The  objectives  of  this  thesis  are  to: 

•  Conduct  a  comparative  analysis  of  current  HSI  policies  and  procedures 
utilized  by  the  Navy. 

•  Identify  the  significant  gaps  in  guidelines  and  policies  in  service 
documentation  and  implementation. 

•  Propose  strengthened  policy,  based  on  the  information  and  knowledge 
gathered  from  the  current  framework  and  gaps,  to  improve  the  efficiency 
and  effectiveness  of  the  acquisition  process. 

D.  RESEARCH  QUESTIONS 

This  thesis  poses  the  question:  What  modifications  can  be  made  within  the  Navy, 
and  the  acquisition  process  as  a  whole,  to  better  address  and  improve  the  application  of 
HSI  in  the  Acquisition,  Technology  and  Logistics  (AT&L)  framework? 

In  addressing  the  question  above,  the  following  questions  were  also  considered: 

•  What  are  the  objectives  of  DoDD  5000.02  with  respect  to  HSI 
requirements  for  the  U.S.  Navy? 

•  What  policies,  procedures,  and  infrastructures  currently  exist  within  the 
U.S.  Navy  to  carry  out  HSI? 

•  What  gaps  exist  between  the  current  policies,  procedures,  and 
infrastructure? 

•  If  gaps  do  exist,  how  can  these  gaps  be  closed? 

E.  METHODOLOGY 

This  thesis  analyzes  how  the  U.S.  Navy  integrates  human  considerations  and  HSI 
into  the  IDAT&L  Framework.  Generalizations  regarding  the  entire  HSI  program  for  the 
U.S.  Navy  are  based  on  the  details  of  the  analysis  of  instruction  and  policy  that  have  been 
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published.  This  thesis  critically  evaluates  U.S.  Navy  policy  and  guidance  for  conducting 
HSI  and  recommends  proposed  solutions  to  fill  gaps  in  the  policy. 

This  thesis  first  establishes  a  baseline  of  HSI  requirements  among  all  Navy 
acquisition  programs  as  outlined  in  the  Department  of  Defense  Directive  (DoDD) 
5000.02.  This  baseline  is  used  to  establish  a  way  in  which  HSI  programs  and  policy  are 
evaluated.  Additionally,  this  thesis  identifies  gaps  in  all  documents  that  need  to  be 
addressed  in  order  to  have  coherent  HSI  policy  and  guidance.  These  gaps,  found  through 
document  review  and  structured  interviews,  are  later  used  to  recommend  revisions  to 
DoD  policy  and  to  establish  a  joint  framework  for  conducting  HSI  throughout  the  entire 
Life  Cycle  of  a  program. 

Based  on  the  results  of  the  analysis,  this  thesis  recommends  revisions  to  HSI 
policy  that  seek  to  reduce  Life  Cycle  cost,  improve  total  system  performance,  and 
enhance  quality  of  life  for  the  end  users,  namely  the  Sailors  and  Marines  who  are 
defending  this  country  on  a  daily  basis  and  who  will  ultimately  reap  the  benefits  of  this 
work.  Those  who  make  decisions  throughout  the  DoD  systems  will  be  better  informed, 
will  understand  how  to  mitigate  Life  Cycle  costs,  and  will  begin  to  recognize  the  human 
as  a  critical  factor  in  any  system  throughout  the  entire  Life  Cycle  process.  The  benefits 
may  be  difficult  to  measure  at  first,  but  over  time  there  will  be  a  greater  understanding  of 
HSI,  which  will  lead  to  a  better  understanding  of  the  trade-offs  that  occur  whenever  a 
system  is  developed. 

The  information  presented  in  this  thesis  was  gathered  from  a  literature  review  of 
other  texts,  periodicals,  directives,  articles,  and  regulations  pertaining  to  HSI  in  the  DoD 
acquisition  process. 

F.  SCOPE  AND  LIMITATIONS 

This  thesis  assumes  that  the  reader  understands  the  basic  principles  and  current 
policies  governing  DoD  systems  acquisition  and  program  management,  as  well  as  DoD 
and  Navy  organizations  involved  therein.  Further,  it  assumes  that  the  reader  has  a  limited 
knowledge  of  HSI  and  will  therefore  explain  HSI  concepts  and  procedures  in  detail.  This 
thesis  focuses  on  the  implementation  of  HSI  through  a  materiel  solutions  approach.  It  is 

important  to  understand  that  HSI  is  also  critical  to  the  process  of  implementing  a 
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nonmateriel  approaeh  and  solution  through  the  use  of  DOTMLPF;  however,  nonmateriel 
approaches  are  not  within  the  scope  of  this  thesis. 


G.  ORGANIZATION 

The  remainder  of  the  thesis  is  organized  as  follows:  Chapter  II  provides  the 
approach  used  to  determine  the  effectiveness  of  current  policy  and  how  gaps  are 
identified.  Chapter  III  describes  a  model  created  to  serve  as  the  ideal  case,  i.e.,  a  way  in 
which  DoD  HSI  policy  could  be  comprehensive  and  complete.  This  model  serves  as  the 
goal  for  future  DoD  HSI  policy  and  guidance,  from  which  analysis  and  recommendations 
are  taken.  Chapter  IV  identifies  and  describes  the  gaps  found  between  current  policy  and 
our  ideal  model  for  this  level  of  documentation.  Chapter  V  proposes  recommendations 
based  on  the  gap  analysis  to  improve  the  HSI  policy  within  the  U.S.  Navy.  Chapter  VI 
summarizes  the  conclusions  derived  from  the  document  analysis  as  well  as  the  new 
framework  recommendations. 
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II.  APPROACH 


A.  DESIGN 

In  order  to  conduct  a  gap  analysis  of  the  current  documentation  pertaining  to  HSI 
within  the  U.S.  Navy,  we  first  propose  an  ideal  conceptual  model,  which  is  explained  in 
detail  in  Chapter  III.  This  model  is  used  to  measure  the  effectiveness  of  the  current  HSI 
policy  and  to  identify  the  gaps  within  the  policy.  This  approach  does  not  involve  studying 
individuals,  but  instead  relies  on  analytical  thought  and  critiques  of  current  DoD  policy 
and  guidance.  The  documents  chosen  for  analysis  were: 

•  DoDD  5000.1  (2003) 

•  DoDI  5000.02  (2008) 

•  CHAIRMAN  OF  THE  JOINT  CHIEFS  OF  STAFF  INSTRUCTION 
(CJCSI)3170.01F(2007) 

•  OFFICE  OF  THE  CHIEF  OF  NAVAL  OPERATIONS  INSTRUCTION 
(OPNAVINST)  5310.23  (2008) 

•  SECRETARY  OF  THE  NAVY  INSTRUCTION  (SECNAVINST) 
5000.2D  (2008) 

•  VIRTUAL  SYSCOM  (VS)  HSI  GUIDE  VOLUME  I  (2005) 

•  VS  HSI  GUIDE  VOLUME  II  (2005) 

•  NAVAL  SEA  SYSTEMS  COMMAND  HUMAN  SYSTEMS 

ENGINEERING  (NAVSEA  HSE)  CODE  OF  BEST  PRACTICES  (2008) 

B.  DESCRIPTION  OF  IDEAL  MODEL 

Microsoft  Visio  was  used  to  construct  a  visual  representation  of  the  ideal  model. 
A  system  engineering/JCIDS  approach  was  used  to  create  a  functional  needs  analysis  to 
break  down  each  component  from  the  highest  to  the  lowest  possible  level.  Each  separate 
item  in  the  model  was  deemed  important  to  HSI,  based  on  the  IDAT&L  Life  Cycle 
Management  Framework.  In  order  to  be  less  biased,  current  policy  and  guidance  was  not 
used  when  creating  this  model,  which  serves  as  an  ideal  model,  without  reference  to 
current  policy. 
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C.  HYPOTHESIS 

There  are  significant  gaps  in  documentation  of  HSI  policy  and  guidance  at  all 
levels  throughout  the  Department  of  the  Navy  (DoN). 

D.  PROCEDURE 

Each  reference  (policies,  guidance,  etc.)  used  in  this  thesis  was  assigned  a  priority 
level,  based  on  the  hierarchical  structure  of  the  U.S.  Navy.  This  priority  level  has 
associated  elements  within  the  model  that  should  be  incorporated  in  the  documentation  at 
that  level.  In  order  to  identify  the  gaps,  each  document  was  read  closely  and  analyzed  as 
it  currently  stands,  looking  for  the  associated  elements  that  should  be  contained  in  it 
according  to  the  ideal  model.  The  elements  not  contained  within  the  document  were 
identified  as  gaps.  After  all  documents  were  analyzed  individually,  three  tracks  were 
created  pertaining  to  the  three  major  U.S.  Navy  Systems  Commands  (SYSCOMs):  Naval 
Sea  Systems  Command  (NAVSEA),  Naval  Air  Systems  Command  (NAVAIR),  and 
Space  and  Naval  Warfare  Systems  Command  (SPAWAR).  Each  of  these  tracks  began  at 
the  highest  level,  the  DoD,  and  ended  at  the  specified  SYSCOM.  This  allowed  us  to  not 
only  identify  gaps  within  individual  documents,  but  also  to  identify  gaps  as  a  whole 
within  the  Navy’s  acquisition  structure.  Recommendations  were  made  for  filling  each  gap 
within  the  parameters  of  the  current  references  as  well  as  within  each  SYSCOM  track. 
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III.  IDEAL  MODEL 


A.  BACKGROUND  ON  THE  IDEAL  MODEL 

This  chapter  explains  the  methodology  used  in  creating  our  ideal  model  for  HSI 
policy  throughout  the  U.S.  Navy.  It  enables  the  reader  to  follow  the  systematic  approach 
taken  to  analyze  HSI  policy  and  guidance  that  exists  in  the  DoN.  This  ideal  model  was 
created  based  on  the  existing  Integrated  Architecture  (lA)  and  existing  policy  and 
guidance,  and  drew  on  our  knowledge  and  understanding  of  the  HSI  process.  The 
existing  lA  was  created  by  numerous  individuals  from  the  U.S.  Navy’s  HSI  Virtual 
Systems  Command  (VSYSCOM).  We  have  amended  portions  of  the  lA  to  implement  the 
policy  that  plays  an  important  role  in  HSI  throughout  the  Navy. 

In  conjunction  with  the  lA,  members  of  the  U.S.  Navy  Virtual  SYSCOM  use  a 
program  called  the  Human  Analysis  and  Requirements  Planning  System  (HARPS), 
which  is  a  tool  that  allows  the  identification  of  automation  through  development  of  the 
HSI  lA.  The  lA  is  embedded  in  HARPS  and,  by  using  the  lA  as  the  basis  for  the  ideal 
model,  by  default  HARPS  is  incorporated  in  the  model. 

Policy  is  the  basis  for  all  tasks  in  the  Navy.  It  mandates  the  tasks  that  should  be 
done,  without  explicitly  stating  how  they  are  to  be  done.  Policy  creates  a  common 
baseline  to  guide  the  SYSCOM  through  complex  undertakings.  To  effectively  mandate  a 
specific  task,  it  should  be  fully  specified  throughout  all  levels  of  authority.  In  the  absence 
of  appropriate  policy,  breakdowns  may  occur  regarding  specific  requirements  to 
accomplish  the  necessary  goal.  These  breakdowns  can  have  significant  effects,  especially 
if  policy  at  the  highest  levels  is  lacking  or  unclear.  Due  to  this  potential  shortcoming, 
policy  is  a  large  part  of  this  ideal  model,  and  results  in  our  model  differing  substantially 
from  the  lA.  Our  focus  on  policy  allows  us  to  analyze  gaps  in  the  IDAT&L  Life  Cycle 
Management  Framework  as  well  as  the  policies  pertaining  to  HSI. 

The  lA  was  developed  to  provide  the  SYSCOMs  with  guidance  in  the  application 
of  HSI,  and  is  complex  and  detailed  in  nature.  Our  ideal  model  is  based  on  the  current  lA, 
but  is  specifically  designed  to  analyze  the  full  range  of  policy  covered  by  the  DoD.  We 
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do  not  suggest  that  the  ideal  model  optimizes  HSl.  Rather,  it  provides  a  comprehensive 
coverage  that  ensures  that  HSl  is  being  fully  implemented  at  all  levels. 

B.  PURPOSE 

The  objective  of  creating  this  ideal  model  is  to  provide  an  overview  of  HSl  policy 
that  allows  HSl  practitioners  the  ability  to  recognize  shortcomings  in  current  policies  and 
guidance.  The  end  goal  of  HSl  is  to  integrate  the  human  into  all  aspects  of  the  system 
design  and  acquisition  process.  It  focuses  on  human  performance  and  trade-offs,  given 
the  specifications  of  each  individual  system.  These  short-comings  are  referred  to  as  gaps, 
and  their  identification  allows  policy  makers  to  see  where  changes  need  to  be  made  in  the 
existing  policy  to  ensure  HSl  is  being  performed  efficiently  and  that  the  appropriate 
people  are  involved  in  its  delivery. 

C.  STRUCTURE  OF  MODEL 

This  section  describes  the  ideal  model  in  a  systematic  manner.  The  ideal  model, 
and  a  brief  explanation  of  each  item,  is  seen  in  Figure  1.  In  order  to  create  a  mental 
picture  for  the  reader,  we  have  condensed  the  model  onto  one  page.  In  the  Appendix,  the 
complete  model  is  laid  out  on  multiple  pages  to  allow  the  reader  the  ability  to  read  the 
text  of  the  model. 
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l  .  -Do  HSI 

“The  process  of  conducting  Human  Systems  Integration  is  intended  to 
integrate  human-related  issues  into  the  development  of  the  product  by 
identifying  specific  human-related  and  mission-related  performance  and 
system  design  requirements,  communicating  those  requirements 
throughout  the  design  process,  and  ensuring  those  requirements  are  met” 
(Virtual  SYSCOM  (VS),  Vol.  2,  2005,  p.  12). 

1.1-  Establish  Policy 

A  planned  course  of  action  that  sets  forth  guiding  principles  and 
procedures  for  ensuring  HSI  is  properly  embedded  throughout  the  entire 
acquisition  strategy,  to  produce  the  most  advantageous  products  to  the 
user,  at  the  lowest  possible  cost. 

1.1.1-  Establish  HSI  Reporting  Authority 

A  structure  created  to  ensure  an  open  line  of  communication  throughout 
all  organizations  in  HSI  and  the  Acquisition  Framework,  from  top  to 
bottom,  to  effectively  track  and  report  all  HSI-relevant  areas  and  provide 
oversight  for  successful  program  acquisition. 

1 . 1 . 1 . 1  -  Operational  Reporting  Authority 

The  Operational  Reporting  Authority  is  tasked  with  “the  employment  of 
the  forces  provided  by  the  administrative  chain  of  command,  in  order  to 
carry  out  missions  in  support  of  the  National  Defense”  (Naval  Officers 
Guide,  1998,  p.  185).  Since  an  Operational  Reporting  Authority  already 
exists  in  the  Navy,  HSI  practitioners  shall  be  embedded  at  all  levels 
throughout  the  reporting  authority  to  ensure  open  lines  of  communication 
and  provide  oversight  in  a  successful  program  acquisition. 

1 . 1 . 1 . 1 . 1  -  Identify  Roles/Key  Players  in  Operational  Reporting  Authority 
Job  title  and  description  for  key  players  serve  as  part  of  the  operational 
reporting  authority.  In  addition  to  meeting  the  requirements  for  the 
specific  job  description,  these  key  personnel  must  also  be  HSI  practioners 
with  documented  education  and  experience. 
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1.1. 1.1. 1.1-  Identify  HSI  Key  Organizations  Throughout  the  Life  Cycle 

Organizations  throughout  the  DoD  and  DoN  are  responsible  for 
implementing  and  overseeing  the  HSI  process  at  various  stages  throughout 
the  IDAT&L  Life  Cycle.  These  HSI  organizations  exist  within  larger 
organizations  that  are  stakeholders  in  the  acquisition  process. 

1.1. 1.1. 1.1.1 

o  DoD  Level 

Refers  to  DoD  and  Chairman  of  the  Joint  Chiefs  of  Staff 
(CJCS)  offices. 

o  Service  Level 

Refers  to  the  Office  of  the  Chief  of  Naval  Operations  (OPNAV) 
and  the  Office  of  the  Secretary  of  the  Navy  (SECNAV)  as  well 
as  VSYSCOM. 

o  Command  Level 

Refers  to  the  System  Commands  (NAVSEA,  NAVAIR,  and 
SPAWAR). 

1 . 1 . 1 .2  -  Administrative  Reporting  Authority 

The  administrative  chain  of  command  is  tasked  with  manning,  training, 
and  equipping  forces.  Since  an  Administrative  Reporting  Authority 
already  exists  in  the  Navy,  HSI  practitioners  shall  be  imbedded  at  all 
levels  throughout  the  reporting  authority  to  ensure  open  lines  of 

communication  and  provide  oversight  in  a  successful  program  acquisition. 
1.1. 1.2.1  -  Identify  Roles/Key  Players  in  the  Administrative  Reporting 
Authority 

Identifies  the  job  title  and  description  for  key  players  that  serve  as  part  of 
the  Administrative  Reporting  Authority.  In  addition  to  meeting  the 
requirements  for  the  specific  job  description,  these  key  personnel  must 
also  be  HSI  practioners,  with  documented  education  and  experience. 
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1.1. 1.2. 1.1  -  Identify  HSI  Key  Organizations  Throughout  the  Life  Cycle 

Organizations  throughout  the  DoD  and  DoN  that  are  responsible  for 

implementing  and  overseeing  the  HSI  process  at  various  stages  throughout 
the  IDAT&L  Life  Cycle.  These  HSI  organizations  exist  within  larger 
organizations  that  are  stakeholders  in  the  acquisition  process. 

1.1. 1.2.1. 1.1 

o  DoD  Level 

Refers  to  DoD  and  CJCS  offices, 
o  Service  Level 

Refers  to  OPNAV  and  SECNAV  as  well  as  VSYSCOM. 

o  Command  Level 

Refers  to  the  System  Commands  (NAVSEA,  NAVAIR, 
and  SPA  WAR). 

1.1.2-  Define  HSI  and  Domains 

“HSI  acknowledges  that  the  human  is  a  critical  component  of  any  complex 
system.  It  is  an  interdisciplinary  approach  that  makes  explicit  the  underlining 
tradeoffs  across  the  HSI  domains,  facilitating  optimization  of  total  system 
performance”  (Miller  &  Shattuck,  2006,  p.  4).  The  domains  of  HSI  are: 
Manpower,  Personnel,  Training,  Human  Factors  Engineering,  Survivability, 
Habitability,  Environment,  Safety,  and  Occupational  Health. 

1 . 1 .2. 1  -  Apply  Defined  HSI  Domains 

Incorporate  all  HSI  domains  listed  above  to  effectively  optimize  total  system 
performance.  Application  of  all  domains  will  allow  for  complete 
trade-off  analysis. 

1.1. 3.1  -  Ensure  Integration  of  Domains 

“Identify  desirable  and  practical  alternatives  among  requirements,  technical 
objectives,  design,  program  schedule,  functional  and  performance  requirements 
and  Life  Cycle  costs  to  optimize  human  performance”  (VS,  Vol.  2,  2005,  p.  14). 
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1.2  -  Participate  in  IDAT«&L  Life  Cycle  Management  Framework 

Actively  engage  in  all  prescribed  portions  of  the  framework,  from  beginning  to 

end,  to  ensure  HSI  is  integrated  throughout  the  entire  framework. 

1.2.1  -  Identify  HSI  Key  Players  Throughout  the  Life  Cycles’  Phases 

Identify  personnel  throughout  the  DoD  and  DoN  that  are  responsible  for 
implementing  and  guiding  the  HSI  process  at  various  stages  throughout  the 
IDAT&L  Life  Cycle.  These  HSI  personnel  are  members  of  a  stakeholder 
command  in  the  acquisition  process. 

1.2. 1.1  -  Transition  Criteria  from  JCIDS  to  the  Materiel  Solutions  Analysis  Phase 

“Entry  point  to  begin  translating  the  HSI  requirements  established  in  JCIDS  into 
materiel  solutions  phase  by  balancing  technology  opportunities,  schedule 
constraints,  funding  availability,  performance  parameters,  and  operational 
requirements”  (VS,  Vol.  2,  2005,  p.  16). 

1.2. 1.1.1  -  Subset  ofI.2.I.l 
Functional  Area  Analysis 

“Identifies  the  mission  area  or  mission  problem  to  be  assessed,  the  concepts  to  be 
examined,  the  timeframe  in  which  the  problem  is  being  assessed,  and  the  scope  of 
the  assessment,  and  describes  the  relevant  objectives  and  concept  of  operations 
(CONOPs)  or  concepts  and  the  relevant  effects  to  be  generated”  (Defense 
Acquisition  University  (DAU),  2005,  p.  B-66  ) 

Functional  Needs  Analysis 

“Assesses  the  ability  of  the  current  and  programmed  war  fighting  systems  to 
deliver  the  capabilities  of  the  Functional  Area  Analysis  identified  under  the  full 
range  of  operating  conditions  and  to  the  designated  measures  of  effectiveness. 
The  FNA  produces  a  list  of  capability  gaps  that  requires  solutions  and  indicates 
the  time  frame  in  which  those  solutions  are  needed.  It  may  also  identify 
redundancies  in  capabilities  that  reflect  inefficiencies”  (DAU,  2005,  p.  B-67) 


17 


Functional  Solutions  Analysis 

“Operationally  assess  all  potential  doctrine,  organization,  training,  materiel, 
leadership  and  education,  personnel  and  facilities  (DOTMLPF),  approaches  to 
solving  (or  mitigating)  the  capability  gaps  (needs)  identified  in  the  Functional 
Needs  Analysis  (FNA),  highlighting  human  systems  impacts”  (VS,  Vol.  2,  2005, 
p.  14). 

HSI  Action  Plan 

“Document  plans  to  implement  HSI  within  the  acquisition  process,  emphasizing 
customer  involvement,  definition  of  processes  for  implementing,  integration  of  all 
HSI  domains,  acquisition  activities,  work  plans,  and  resources”  (VS,  Vol.  2,  2005, 
p.  18).  This  will  not  be  a  stand-alone  document;  it  will  be  integrated  with  the 
systems  engineering  plan(s). 

Acknowledgement  of  Materiel  Solution 

“Identify  the  HSI  domain  impacts  of  the  proposed  materiel  solutions”  (VS,  Vol.  2, 
2005,  p.  15). 

Initial  Capabilities  Document 

“Generate  the  HSI  inputs  for  the  ICD  and  review  the  overall  HSI  inclusion  and 
integration”  (VS,  Vol.  2,  2005,  p.  16). 

1.2. 1.2  -  Materiel  Solutions  Analysis  Phase  (MSA) 

“The  purpose  of  this  phase  is  to  assess  potential  materiel  solutions  and  to  satisfy 
the  phase- specific  entrance  criteria  for  the  next  program  milestone  designated  by 
the  MDA”  (DoD,  2008,  p.  14). 

1.2. 1.2.1  -  Subset  of  1.2. 1.2 

Analysis  of  Alternatives  (AoA)  Plan 

“Perform  HSI  assessment  of  advantages  and  disadvantages  of  alternatives  being 
considered  to  satisfy  capabilities,  including  a  sensitivity  of  each  alternative  to 
possible  changes  in  key  assumptions  or  variables.  These  assessments  should  be 
considered  in  selection  of  the  preferred  materiel  solution”  (VS,  Vol.  2,  2005,  p. 
19). 


18 


Technology  Development  Strategy 

“Assure  Request  for  Proposal  (RFP)  includes  HSI  domain  and  integration 
requirements  within  the  Statement  of  Work  (SOW),  Specification  and  Contract 
Data  Requirements.  Review  and  evaluate  contractor  response  to  RFP  for  HSI 
considerations  to  approach,  cost  estimate,  and  resources”  (VS,  Vol.  2,  2005,  p. 
23). 

Test  and  Evaluation  Strategy 

This  is  a  document  “that  describes  risk  reduction  efforts  across  the  range  of 
activities  that  will  ultimately  produce  a  valid  evaluation  of  operational 
effectiveness,  suitability,  and  survivability  before  full-rate  production  and 
deployment”  (DAU,  2004,  p.  477). 

Materiel  Development  Decision 

This  allows  a  program  to  enter  into  the  Acquisition  Framework/system.  It  is  a 
mandatory  decision  point  that  is  developed  from  the  initial  capabilities  document 
(ICD),  as  well  as  all  preliminary  concepts,  needs,  and  capabilities,  and  allows 
optimal  trade-offs  to  be  performed. 

System  Engineering  Plan 

This  is  a  “program’s  overall  technical  approach  including  the  systems  engineering 
process;  resources;  and  key  technical  tasks,  activities,  and  events  along  with  their 
metrics  and  success  criteria.  Integration  and  linkage  with  other  program 
management  control  efforts  is  fundamental  to  successful  application.  This  plan 
must  address  the  who,  what,  when,  where,  why  and  how  of  the  applied  system” 
(DAU,  2004,  p.  166). 

HSI  Action  Plan 

“Document  plans  to  implement  HSI  within  the  acquisition  process  emphasizing 
customer  involvement,  definition  of  processes  for  implementing,  integration  of  all 
HSI  domains,  acquisition  activities,  work  plans,  and  resources.  Additionally,  this 
includes  the  aggregation  of  all  inputs  available  at  this  stage  of  the  program  to 
ensure  that  all  HSI  needs  and  constraints  of  the  concept  definition  are  completely 
captured  and  managed  as  an  integrated  whole,  and  that  all  of  the  HSI  needs  and 
constraints  can  be  met  by  each  of  the  concept  alternatives  under  consideration” 
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(VS,  Vol.  2,  2005,  p.  18).  This  will  not  be  a  stand-alone  document;  it  will  be 
integrated  with  the  systems  engineering  plan(s). 

Support  and  Maintenance  Concepts 

“[Support  and]  maintenance  considerations,  constraints,  and  plans  for  operational 
support  of  the  sy stem/ equipment  under  development”  (DAU,  2005,  p.  B-97) 

Cost  and  Manpower  Estimates 

“The  estimate  of  dollars  and  personnel  required  to  operate,  maintain,  support,  and 
provide  system-related  training,  in  advance  of  the  approval  of  the  development,  or 
production  and  deployment  of  the  system.  These  estimates  should  be  consistent 
with  manpower  levels  assumed  in  the  affordability  assessment  and  cost 
requirements”  (DAU,  2004,  p.  52). 

Alternative  Concepts 

“Identify  desirable  and  practical  alternatives  among  requirements,  technical 
objectives,  design,  program  schedule,  functional  and  performance  requirements 
and  Life  Cycle  cost  to  optimize  human  performance”  (VS,  Vol.  2,  2005,  p.  14). 

User  Input/Feedback 

The  user  needs  to  provide  their  needs  and  constraints  to  the  manufacturer  in  order 
to  keep  the  program  aligned  with  the  initial  demand  of  the  user. 

Initial  Capabilities  Document 

“Generate  the  HSI  inputs  for  the  ICD  and  review  the  overall  HSI  inclusion  and 
integration”  (VS,  Vol.  2,  2005,  p.  16). 

Preliminary  System  Specification 

“States  the  [initial]  system  level  functional  and  performance  requirements, 
interfaces,  adaptation  requirements,  security  and  privacy  requirements,  computer 
resource  requirements,  design  constraints  (including  software  architecture,  data 
standards,  programming  language),  software  support  and  precedence 
requirements,  and  developmental  test  requirements  for  a  given  system”  (DAU, 
2005,  p.  B-161) 

Initial  Training  Systems  Plan 

“Develop  a  training/instructional  system  that  should  be  employed  by 
transformational  training  concepts,  strategies,  and  tools  such  as  computer  based 
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and  interactive  courseware,  simulators,  and  embedded  training  consistent  with 
strategy,  goals  and  objectives  of  the  proposed  system”  (DAU,  2004,  p.  253). 

Draft  Key  Performance  Parameters  (KPPs) 

“[Draft]  attributes  or  characteristics  of  a  system  that  are  considered  critical  or 
essential  to  the  development  of  an  effective  military  capability  and  those 
attributes  that  make  a  significant  contribution  to  the  key  characteristics  as  defined 
in  the  Joint  Operations  Concept  [especially  in  the  HSI  domains]”  (DAU,  2005,  p. 
B-91) 

Name  Materiel  Solution  Manager 

Materiel  Solution  Manager  “is  responsible  for  managing  the  HSI  related  program 
requirements  from  concept  to  disposal,  bringing  together  all  stake  holders  and 
involving  industry  (except  during  competition  phases)  under  their  leadership  and 
must  be  able  to  balance  trade-offs  between  performance,  cost  and  time  within 
boundaries  set  by  the  approving  authority”  (VS,  Vol.  2,  2005,  p.  17). 

System  Concept 

“A  formal  document  that  describes  the  intended  purpose,  employment, 
deployment,  and  support  of  a  system”  (DAU,  2005,  p.  B-161) 

1.2. 1.3  -  Transition  Criteria  from  Material  Solutions  Analysis  (MSA)  to  Technology 
Development  (TD)  (Milestone  A) 

Transition  between  phases  is  delineated  by  requirements  that  must  be  met  before 

entrance  to  the  next  phase. 

1.2. 1.3.1  -  Subset  of  1.2. 1.3 

Draft  Capability  Development  Document  (CDD) 

“A  [draft]  document  that  captures  the  information  necessary  to  develop  a 
proposed  program  [throughout  the  Life  Cycle].  The  CDD  outlines  an  affordable 
increment  of  militarily  useful,  logistically  supportable,  and  technically  mature 
capability”  (CJCSI  3170.01G,  2009,  GL-5). 

Milestone  Exit  Criteria 

“The  point  at  which  a  recommendation  is  made  and  approval  sought  regarding 
starting  or  continuing  an  acquisition  program,  i.e.,  proceeding  to  the  next  phase” 
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(DAU,  2005,  p.  B-104).  The  purpose  is  to  establish  (at  the  beginning  of  each 
phase)  what  criteria  must  be  met  to  exit  that  phase. 

1.2. 1.4  -  Technology  Development  (TD)  Phase 

“This  phase  reduced  technology  risk  and  determines  the  appropriate  set  of 
technologies  to  be  integrated  into  a  full  system.  Technology  development  is  a 
continuous  technology  discovery  and  development  process  that  reflects  close 
collaboration  between  the  science  and  technology  community,  the  user,  and  the 
developer.  Technology  development  is  an  iterative  process  of  assessing 
technologies  and  refining  user  performance  parameters”  (VS,  Vol.  2,  2005,  p.  22). 
1.2.1.4.1- Subset  of  1.2. 1.4 

Information  Support  Plan  (ISP) 

“The  ISP  contains  interface  descriptions,  infrastructure  and  support  requirements, 
standards  profiles,  measures  of  performance,  and  interoperability  shortfalls” 

(DAU,  2005,  p.  B-79) 

Systems  Performance  Specification 

A  plan  that  delineates  the  specifications  required  by  the  user  for  a  successful 
completion.  These  specifications  include,  but  are  not  limited  to,  test  methods, 
performance  testing  requirements,  safety  considerations  and  requirements, 
environmental  considerations  and  requirements,  as  well  as  quality  and 
completion  requirements. 

Acquisition  Strategy 

“A  business  and  technical  management  approach  designed  to  achieve  program 
objectives  within  the  resource  constraints  imposed.  It  is  the  framework  for 
planning,  directing,  contracting  for,  and  managing  a  program.  It  provides  a  master 
schedule  for  research,  development,  test,  production,  fielding,  modification, 
postproduction  management,  and  other  activities  essential  for  program  success. 
The  acquisition  strategy  is  the  basis  for  formulating  functional  plans  and 
strategies”  (DAU,  2005,  p.  B-4) 
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Footprint  Reduction 

Reduce  footprints  through  the  use  of  alternative  concepts/solutions  to  mitigate  the 
negative  effects  of  a  particular  footprint. 

Affordability  Assessment 

“[An  assessment  generating  a]  determination  of  the  Life  Cycle  Cost  of  an 
acquisition  program  in  consonance  with  the  long-range  investment  and  force 
structure  plans  of  the  DoD  or  individual  DoD  Components”  (DAU,  2005,  p.  B-7) 
KPPs 

“Attributes  or  characteristics  of  a  system  that  are  considered  critical  or  essential  to 
the  development  of  an  effective  military  capability  and  those  attributes  that  make 
a  significant  contribution  to  the  key  characteristics  as  defined  in  the  Joint 
Operations  Concept  [especially  in  the  HSI  domains]”  (DAU,  2005,  pg.  B-91) 

HSI  Action  Plan 

“Document  plans  to  implement  HSI  within  the  acquisition  process  emphasizing 
customer  involvement,  definition  of  processes  for  implementing,  integration  of  all 
HSI  domains,  acquisition  activities,  work  plans,  and  resources”  (VS,  Vol.  2,  2005, 
p.  18).  This  will  not  be  a  stand-alone  document;  it  will  be  integrated  with  the 
systems  engineering  plan(s). 

Test  and  Evaluation  (T&E)  Master  Plan 

“Documents  the  overall  structure  and  objectives  of  the  Test  and  Evaluation  (T&E) 
program.  It  provides  a  framework  within  which  to  generate  detailed  T&E  plans 
and  it  documents  schedule  and  resource  implications  associated  with  the  T&E 
program.  The  TEMP  identifies  the  necessary  Developmental  Test  and  Evaluation 
(DT&E),  Operational  Test  and  Evaluation  (OT&E),  and  Live  Fire  Test  and 
Evaluation  (LFT&E)  activities.  It  relates  program  schedule,  test  management 
strategy  and  structure,  and  required  resources  to:  Critical  Operational  Issues 
(COIs),  Critical  Technical  Parameters  (CTPs),  objectives  and  thresholds 
documented  in  the  Capability  Development  Document  (CDD),  evaluation  criteria, 
and  milestone  decision  points”  (DAU,  2005,  B-166). 
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Integrated  Baseline  Review 

“Review  of  the  Performance  Measurement  Baseline  used  to  determine 
compliance  and  integration  of  domain  related  topics  throughout  the  system” 

(DAU,  2005,  p.B-82). 

Manpower  Estimates 

“The  estimate  of  personnel  required  to  operate,  maintain,  support,  and  provide 
system-related  training,  in  advance  of  the  approval  of  the  development,  or 
production  and  deployment  of  the  system.  These  estimates  should  be  consistent 
with  manpower  levels  assumed  in  the  affordability  assessment  and  cost 
requirements”  (DAU,  2004,  p.  68). 

System  Threat  Assessment 

Assessment  made  to  summarize  “significant  changes  in  the  threat  environment  as 
well  as  a  discussion  of  the  operational  threat  environment,  adversary  capability(s) 
[sic]  that  may  affect  operation  of  the  system,  system  specific  threat,  reactive 
threat,  and  technologically  feasible  threats”  (DAU,  2004,  p.  392). 

User  Input/Feedback 

The  user  needs  to  provide  their  needs  and  constraints  to  the  manufacturer  in  order 
to  keep  the  program  aligned  with  the  initial  demand  of  the  user. 

Proposed  Training  Systems  Plan 

“Document  and  update  the  initial  “training/instructional  system  that  should  be 
employed  by  transformational  training  concepts,  strategies,  and  tools  such  as 
computer  based  and  interactive  courseware,  simulators,  and  embedded  training 
consistent  with  strategy,  goals  and  objectives  of  the  proposed  system”  (DAU, 
2004,  p.  253). 

Technology  Readiness  Assessment 

“The  system  components  are  substantiated  (e.g.,  through  analyses,  modeling  and 
simulation,  demonstrations,  etc.)  to  allow  verification  of  the  components  into  an 
overall  system  for  further  validation”  (VS,  Vol.  2,  2005,  p.  27). 
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System  Support  and  Maintenance  Objectives 

“[Support  and]  maintenance  considerations,  constraints,  and  plans  for  operational 
support  of  the  sy stem/ equipment  under  development”  (DAU,  2005,  p.  B-97). 
Programmatic  Environment,  Safety,  and  Health  Evaluation  (PESHE) 

Develop  design  options  and  specific  design  requirements  to  satisfy  requirements 
in  the  areas  of  Environment,  Safety,  and  Occupational  Health. 

Systems  Engineering  Plan 

“This  is  a  program’s  overall  technical  approach  including  the  systems  engineering 
process;  resources;  and  key  technical  tasks,  activities,  and  events  along  with  their 
metrics  and  success  criteria.  Integration  and  linkage  with  other  program 
management  control  efforts  is  fundamental  to  successful  application.  This  plan 
must  address  the  who,  what,  when,  where,  why  and  how  of  the  applied  system” 
(DAU,  2004,  p.  80). 

Program  Protection  Plan 

“[A  plan  set  forth  to]  safeguard  defense  systems  and  Technical  Data  (TD) 
anywhere  in  the  acquisition  process,  to  include  the  technologies  being  developed, 
the  support  systems,  [within  military  and  HSI  applications]”  (DAU,  2005,  p.  B- 
133). 

Domain  Implications 

Specific  side  effects  of  domain  integration  and  trade-offs  throughout  the  system. 
By  incorporating  domain  integration,  a  hierarchy  of  priorities  must  be  established 
to  optimize  the  system  through  conducting  the  necessary  trade-offs. 

Preliminary  Design  Review  (PDR) 

The  PDR  will  inform  requirement  trades;  improve  cost  estimation;  and  indentify 
remaining  design,  integration,  and  manufacturing  risk.  The  PDR  shall  be 
conducted  at  the  system  level  and  include  user  representatives  (DoD,  2008). 

Risk  Assessment 

“Identification  and  analysis  of  potential  cost  and  risk  to  the  program  plan.  The 
risk  assessment  should  include  but  not  be  limited  to  cost,  performance,  and 
schedule”  (VS,  Vol.  2,  2005,  p.  28). 
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1.2. 1.5  -  Transition  From  TD  to  Engineering  and  Manufacturing  Development 
(EMD)  (Milestone  B) 

Transition  between  phases  is  delineated  by  requirements  that  must  be  met  before 
entrance  to  the  next  phase. 

1.2. 1.5.1  -  Subset  of  1.2. 1.5 

Milestone  Exit  Criteria 

“The  point  at  which  a  recommendation  is  made  and  approval  sought  regarding 
starting  or  continuing  an  acquisition  program,  i.e.,  proceeding  to  the  next  phase” 
(DAU,  2005,  p.  B-104).  The  purpose  is  to  establish  (at  the  beginning  of  each 
phase)  what  criteria  must  be  met  to  exit  that  phase. 

CDD 

“Primary  means  of  defining  authoritative,  measurable,  and  testable  capabilities 
needed  by  the  war  fighters  to  support  the  EMD  phase”  (DAU,  2004,  p.  220).  The 
CDD  focuses  on  affordability,  reliability,  and  supportability. 

Name  PM 

Identify  and  establish  a  PM  to  effectively  work  with  the  Materiel  Solution 
Manager  in  order  to  ensure  the  continuity  of  the  work  previously  done,  as  well  as 
maintain  effective  use  of  HSI  domain  practitioners  throughout  the  rest  of  the 
Life  Cycle. 

1.2.1.6- EMD  Phase 

“The  initial  HSI  activity  in  this  phase  is  to  develop  human-centered  design 
concepts  in  the  context  of  alternative  system  design  concepts.  HSI  concepts 
include  human-machine  interfaces,  human-computer  interface  (HCI), 
workstations,  procedures/documentation/decision  aiding,  work  space/facility, 
maintainability  design,  safety  and  health  hazard  avoidance  design  and  training 
systems  design.  The  purposed  of  EMD  is  to  develop  a  system;  reduce  integration 
and  manufacturing  risk;  ensure  operationally  supportability  with  particular 
attention  to  reducing  the  logistics  footprint;  implement  HSI;  design  for  product 
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ability;  ensure  affordability  and  proteetion  of  Critical  Program  Information  (CPI); 
and  demonstrate  system  integration,  interoperability,  safety,  and  utility”  (VS,  Vol. 
2,  2005,  p.  29). 

1.2. 1.6.1  -  Subset  of  1.2. 1.6 

HSI  Action  Plan 

“Document  plans  to  implement  HSI  within  the  acquisition  process  emphasizing 
customer  involvement,  definition  of  processes  for  implementing,  integration  of  all 
HSI  domains,  acquisition  activities,  work  plans,  and  resources”  (VS,  Vol.  2,  2005, 
p.  18).  This  will  not  be  a  stand-alone  document;  it  will  be  integrated  with  the 
systems  engineering  plan(s). 

Product  Support  Package 

“Identify  the  activities,  resources,  schedule  and  critical  integration  requirements 
for  the  current  phase”  (VS,  Vol.  2,  2005,  p.  31). 

ISP 

“The  ISP  contains  interface  descriptions,  infrastructure  and  support  requirements, 
standards  profiles,  measures  of  performance,  and  interoperability  shortfalls” 

(DAU,  2005,  p.  B-79) 

PESHE 

Develop  design  options  and  specific  design  requirements  to  satisfy  requirements 
in  the  areas  of  Environment,  Safety,  and  Occupational  Health. 

Integrated  System  Design 

Combine  all  inputs  available  at  this  stage  of  the  program  to  ensure  that  all  HSI 
needs  and  constraints  of  the  concept  are  completely  captured  and  managed  as  an 
integrated  whole,  and  that  all  of  the  HSI  needs  and  constraints  can  be  met  by  each 
of  the  concept  alternatives  under  consideration. 

Approved  Training  Systems  Plan 

Finalize  the  “training/instructional  system  that  should  be  employed  by 
transformational  training  concepts,  strategies,  and  tools  such  as  computer  based 
and  interactive  courseware,  simulators,  and  embedded  training  consistent  with 
strategy,  goals  and  objectives  of  the  proposed  system”  (DAU,  2004,  p.  253). 

Critical  Design  Review  (CDR) 
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“A  multi-disciplined  technical  review  to  ensure  that  a  system  can  proceed  into 
fabrication,  demonstration,  and  test  and  can  meet  stated  performance 
requirements  within  cost,  schedule,  risk,  and  other  system  constraints.  Generally 
this  review  assesses  the  system  final  design  as  captured  in  product  specifications 
for  each  configuration  item  in  the  system’s  product  baseline,  and  ensures  that 
each  configuration  item  in  the  product  baseline  has  been  captured  in  the  detailed 
design  documentation”  (DAU,  2004,  p.  127). 

Systems  Engineering  Plan 

“This  is  a  program’s  overall  technical  approach  including  the  systems  engineering 
process;  resources;  and  key  technical  tasks,  activities,  and  events  along  with  their 
metrics  and  success  criteria.  Integration  and  linkage  with  other  program 
management  control  efforts  is  fundamental  to  successful  application.  This  plan 
must  address  the  who,  what,  when,  where,  why  and  how  of  the  applied  system” 
(DAU,  2004,  p.  80). 

Configuration  Items  Component-Level  Specification 

“Comprehensive  and  iterative  processes  to  convert  each  required  capability  into  a 
system  performance  specification;  translate  user-defined  performance  parameters 
into  configured  systems;  integrate  the  technical  inputs  of  the  entire  design  system; 
transition  technology  from  the  technology  based  into  program  specific  efforts;  and 
verify  that  designs  meet  operational  needs”  (VS,  Vol.  2,  2005,  p.  31). 

Key  Performance  Parameters  (KPPs) 

“Attributes  or  characteristics  of  a  system  that  are  considered  critical  or  essential  to 
the  development  of  an  effective  military  capability  and  those  attributes  that  make 
a  significant  contribution  to  the  key  characteristics  as  defined  in  the  Joint 
Operations  Concept  [especially  in  the  HSI  and/or  HSI  domains]”  (DAU,  2005,  p. 
B-91) 

User  Input/Feedback 

The  user  needs  to  provide  their  needs  and  constraints  to  the  manufacturer  in  order 
to  keep  the  program  aligned  with  the  initial  demand  of  the  user. 

Initial  Product  Baseline 
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“Construct  or  assemble  hardware  and  software  components  and  material  to 
support  human  eomponents,  speeified  by  the  system  design  and  maintenance 
concept”  (VS,  Vol.  2,  2005,  p.  43). 

T«&E  Report 

A  report  of  the  findings  found  during  T&E,  speeifically  citing  HSI  domains  and 
human  interactions  as  found  through  the  Operational  and  Developmental  Test  and 
Evolution  events. 

OT&E 

“Through  [Operational]  Test  and  Evaluation  events  and  other  aetivities  verify  and 
validate,  the  design  solutions  relating  to  the  entire  system,  but  speeifically 
highlighting  HSI  domains  that  satisfy  requirements.  Perform  evaluations  at  the 
total  system  level,  demonstrating  performance  in  the  expeeted  operational 
environment.  Operational  environment  includes  operational  supportability  and 
interoperability”  (VS,  Vol.  2,  2005,  p.  35). 

DT&E 

“Through  [Developmental]  Test  and  Evaluation  events  and  other  aetivities,  verify 
and  validate,  the  design  solutions  relating  to  HSI  domains  to  satisfy  requirements” 
(VS,  Vol.  2,  2005,  p.  35). 

Post-PDR  Assessment 

Assessment  eondueted  by  the  PM  and  Milestone  Decision  Authority  to  ensure 
that  the  PDR  report  reflects  any  requirements  trades  based  on  the  assessment  of 
cost,  schedule,  and  performance  risk  (DoD,  2008). 

Post-CDR  Assessment 

Assessment  eonsiders  whether,  based  on  the  PM’s  report,  the  program  is  able  to 
provide  eapability  consistent  with  the  aequisition  baseline  approved  at  Milestone 
B  (DoD,  2008). 

1.2. 1.7  -  Transition  from  EMD  to  PD  (Milestone  C) 

Transition  between  phases  is  delineated  by  requirements  that  must  be  met  before 
entranee  to  the  next  phase. 

1.2. 1.7.1  -  Subset  of  1.2. 1.7 

Milestone  Exit  Criteria 
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“Conduct  documentation  reviews  and  other  activities  to  eomplete  approval  and 
publieation  of  program  doeumentation”  (VS,  Vol.  2,  2005,  p.  36).  The  purpose  is 
to  establish  (at  the  beginning  of  each  phase)  what  criteria  must  be  met  to  exit  that 
phase. 

CPD 

“Document  contains  refmed/desired  operational  capabilities  and  expected  system 
performance  that  are  used  throughout  the  test  and  evaluation  phase.  These  inputs 
are  used  to  update  the  Test  and  Evaluation  Master  Plan  for  the  Milestone  C 
decision  and  subsequent  updates  later  in  production  and  deployment.  [This 
document]  foeuses  on  evaluation  of  the  systems’  operational  effeetiveness, 
suitability,  and  survivability’’  (DAU,  2004,  p.  431). 

1.2. 1.8  -  Production  and  Deployment  (PD)  Phase 

“The  system  is  produeed  and  fielded,  continually  undergoing  test  and  evaluation 
to  ensure  that  it  is  being  implemented  as  designed  and  that  the  design  will  meet 
mission  requirements.  During  the  Production  and  Deployment  Phase,  the  system 
should  aehieve  operational  capability  that  satisfies  mission  needs.  During  this 
phase  the  production  and  deployment  team  is  responsible  for  managing  the  HSl 
related  program  requirements  from  eoncept  to  disposal,  bringing  together  all 
stakeholders  and  Industry  to  balance  tradeoffs  between  performanees,  eost  and 
time’’  (VS,  Vol.  2,  2005,  p.  37). 

1.2. 1.8  .1  -  Subset  of  1.2. 1.8 
HSI  Action  Plan 

“Document  plans  to  implement  HSI  within  the  acquisition  process  emphasizing 
eustomer  involvement,  definition  of  processes  for  implementing,  integration  of  all 
HSI  domains,  acquisition  activities,  work  plans,  and  resourees.  This  will  be  a 
stand  alone  doeumenf’  (VS,  Vol.  2,  2005,  p.  18). 

User  Input/Feedback 

The  user  needs  to  provide  their  needs  and  constraints  to  the  manufacturer  in  order 
to  keep  the  program  aligned  with  the  initial  demand  of  the  user. 

Production  Baseline 


30 


“The  document  which  describes  the  [baseline]  for  employment  of  the 
manufacturing  resources  to  produce  the  required  products  or  systems,  on  time, 
and  within  cost  constraints”  (DAU,  2005,  p.  B-127). 

Operational  Readiness  Assessment 

“Evaluate  prototypes,  early  production  versions  of  the  system,  and  training 
capabilities  to  identify  areas  in  which  performance  of  the  fielded  version  may  not 
be  satisfactory.  Review  other  evaluations  of  the  system,  preliminary  user 
feedback,  and  training  feedback  to  determine  other  possible  shortcomings  or  other 
specific  areas  in  which  performance,  effectiveness,  or  efficiency  may  be 
improved”  (VS,  Vol.  2,  2005,  p.  39). 

Product  Support  Package 

“Identify  the  activities,  resources,  schedule  and  critical  integration  requirements 
for  the  current  phase”  (VS,  Vol.  2,  2005,  p.  41). 

Implement  Maintenance  Objectives 

“[Implement]  maintenance  considerations,  constraints,  and  plans  for  operational 
support  of  the  sy stem/ equipment  under  development”  (DAU,  2005,  p.  B-97). 
PESHE 

Revise  and  develop  design  options  and  specific  design  requirements  to  satisfy 
requirements  in  the  areas  of  Environment,  Safety,  and  Occupational  Health. 

Implement  Training  Plan 

Deploy/field  “training/instructional  system  that  should  be  employed  by 
transformational  training  concepts,  strategies,  and  tools  such  as  computer  based 
and  interactive  courseware,  simulators,  and  embedded  training  consistent  with 
strategy,  goals  and  objectives  of  the  proposed  system”  (DAU,  2004,  p.  253). 
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Cost  and  Manpower  Estimate 

“The  estimate  of  dollars  and  personnel  required  to  operate,  maintain,  support,  and 
provide  system-related  training,  in  advance  of  the  approval  of  the  development,  or 
production  and  deployment  of  the  system.  These  estimates  should  be  consistent 
with  manpower  levels  assumed  in  the  affordability  assessment  and  cost 
requirements”  (DAU,  2004,  p.  52). 

Systems  Engineering  Plan 

“This  is  a  program’s  overall  technical  approach  including  the  systems  engineering 
process;  resources;  and  key  technical  tasks,  activities,  and  events  along  with  their 
metrics  and  success  criteria.  Integration  and  linkage  with  other  program 
management  control  efforts  is  fundamental  to  successful  application.  This  plan 
must  address  the  who,  what,  when,  where,  why  and  how  of  the  applied  system” 
(DAU,  2004,  p.  80). 

1 .2. 1 .9  -  Operations  and  Support  Phase 

“Operations  and  support  includes  the  activities  necessary  to  sustain  the  system — 
including  training,  maintenance,  modernization,  and  upgrades  -  in  a  cost-effective 
manner  throughout  the  Life  Cycle.  The  operations  and  support  team  is  responsible 
for  managing  HSI  related  program  requirements  from  concept  to  disposal, 
bringing  together  all  stakeholders  and  Industry  to  balance  tradeoff  between 
performance,  cost,  and  time”  (VS,  Vol.  2,  2005,  p.  40). 

1.2.1.9.1- Subset  of  1.2. 1.9 

In-Service  Review  Data 

“Review  existing  data;  participate  in  external  -  ongoing  data  collection  activities; 
conduct  focused  human  performance  assessments;  a  model  should  include  an 
issue  repository  that  should  be  reviewable  and  accessible  by  all  stakeholders” 
(VS,  Vol.  2,  2005,  p.  42). 
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Disposal  Plan 

A  plan  that  guides  the  demilitarization  process  and  disposal  in  “accordance  with 
all  legal  and  regulatory  requirements  and  policy  relating  to  safety  (including 
explosive  safety),  security,  and  the  environment”  (DoD,  2008,  p.  29). 

Cost  and  Manpower  Summary 

“The  [actual  number]  of  dollars  and  personnel  required  to  operate,  maintain, 
support,  and  provide  system-related  training,  in  advance  of  the  approval  of  the 
development,  or  production  and  deployment  of  the  system.  These  [numbers] 
should  be  consistent  with  manpower  levels  assumed  in  the  estimates,  affordability 
assessment  and  cost  requirements”  (DAU,  2004,  p.  52). 

HSI  Action  Plan 

“Document  plans  to  implement  HSI  within  the  acquisition  process  emphasizing 
customer  involvement,  definition  of  processes  for  implementing,  integration  of  all 
HSI  domains,  acquisition  activities,  work  plans,  and  resources.  This  will  be  a 
stand-alone  document”  (VS,  Vol.  2,  2005,  p.  18). 

Product  Support  Package 

“Identify  the  activities,  resources,  schedule  and  critical  integration  requirements 
for  the  current  phase”  (VS,  Vol.  2,  2005,  p.  17). 

PESHE 

Revise  and  develop  design  options  and  specific  design  requirements  to  satisfy 
requirements  in  the  areas  of  Environment,  Safety,  and  Occupational  Health. 

Inputs  to  CDD  (Next  Increment) 

“Primary  means  of  defining  authoritative,  measurable,  and  testable  capabilities 
needed  by  the  war  fighters  to  support  the  EMD  phase”  (DAU,  2004,  p.  220).  The 
CDD  focuses  on  affordability,  reliability,  and  supportability. 

Revised  Training  Systems  Plan  (For  Upgrades/Next  Increment) 

Document  and  update  the  “training/instructional  system  that  should  be  employed 
by  transformational  training  concepts,  strategies,  and  tools  such  as  computer 
based  and  interactive  courseware,  simulators,  and  embedded  training  consistent 
with  strategy,  goals  and  objectives  of  the  proposed  system”  (DAU,  2004, 
p.  253). 


33 


New  Program  Initiation 

Appropriate  Life  Cyele  support  organization  designs  and  developments  a  detailed 
solution  to  address  [new  program  initiatives]. 

Operation  Readiness  Assessment 

“Evaluate  prototypes,  early  produetion  versions  of  the  system,  and  training 
capabilities  to  identify  areas  in  which  performance  of  the  fielded  version  may  not 
be  satisfactory.  Review  other  evaluations  of  the  system,  preliminary  user 
feedback,  and  training  feedback  to  determine  other  possible  shortcomings  or  other 
specific  areas  in  which  performance,  effectiveness,  or  efficiency  may  be 
improved”  (VS,  Vol.  2,  2005,  p.  39). 

Life  Cycle  Sustainment 

“Life  Cycle  sustainment  planning  and  execution  seamlessly  span  a  system’s  entire 
Life  Cycle,  from  materiel  solution  analysis  to  disposal.  It  translates  force  provider 
capability  and  performance  requirements  into  tailored  product  support  to  achieve 
specified  and  evolving  Life  Cycle  product  support  availability,  reliability,  and 
affordability  parameters”  (DoD,  2008,  p.  28). 

Specifications  for  System  Modifications/Upgrades 

“Evaluation,  by  applicable  stakeholders,  of  alternative  corrective  actions  to 
prioritize  the  solutions  impact  on  the  mission  and  fund  the  preferred  system 
implementation  in  accordance  with  program  constraints”  (VS,  Vol.  2,  2005,  p. 
43). 

User  Input/Feedback 

The  user  needs  to  provide  their  needs  and  constraints  to  the  manufacturer  in  order 
to  keep  the  program  aligned  with  the  initial  demand  of  the  user. 

Implement  Maintenance  Objectives 

“[Implement]  maintenance  considerations,  constraints,  and  plans  for  operational 
support  of  the  sy stem/ equipment  under  development”  (DAU,  2005,  p.  B-97) 
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D.  FUTURE  OF  MODEL 


The  field  of  HSI  continues  to  evolve  and  changes  occur  frequently.  As  gaps  are 
identified,  they  are  then  filled,  which  will  change  the  nature  of  the  findings  in  this  thesis. 
However,  as  HSI  matures,  the  model  proposed  herein  serves  as  a  baseline  on  which  to 
build.  Modifications  are  expected  and  welcome,  as  they  will  enrich  the  field  of  study. 

E.  SUMMARY 

As  seen  from  the  above  definitions,  we  have  provided  both  a  model  and 
operational  definitions  for  each  of  the  elements  of  the  model  to  allow  the  reader  to  fully 
understand  the  criteria  that  is  needed  to  address  and  fill  the  gaps  in  policy  that  are  noted 
in  the  next  chapter.  These  definitions  allow  us  to  find  the  gaps  in  current  policy  and 
address  them  accordingly.  In  the  next  chapter,  a  gap  analysis  is  performed,  based  on  the 
definitions  found  in  this  chapter,  and  recommendations  are  made  to  help  close  the 
noted  gaps. 
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IV.  GAP  ANALYSIS  OF  DOCUMENTATION  AND 
RECOMMENDATIONS 


A.  ANALYSIS 

As  mentioned  in  earlier  chapters,  each  reference  (policies,  documents,  etc.)  used 
in  this  thesis  were  assigned  a  priority  level  based  on  the  hierarchy  of  the  Navy  structure. 
This  priority  level  has  associated  elements  within  the  model  that  should  be  incorporated 
in  the  documentation  at  that  particular  level.  In  order  to  identify  gaps  in  each  document, 
we  closely  read  and  analyzed  the  current  document,  looking  for  areas  that  met  the  criteria 
laid  out  in  the  model.  The  elements  that  were  not  contained  within  the  document,  but 
were  identified  in  the  model,  were  noted  as  gaps  and  recorded  in  this  chapter. 
Recommendations  were  then  be  made  to  identify  ways  to  fill  those  recorded  gaps. 

B.  PRIORITY  LEVEL  OF  DOCUMENTS 

The  following  documents  were  been  broken  down  and  were  assigned  a  particular 
priority  level  based  on  the  hierarchy  of  the  authority  from  which  the  document  was 
released.  The  references  were  assigned  a  level  number  ranging  from  1  to  3,  with  1  being 
the  highest  level  of  DoD  and  Navy  authority  and  3  being  the  lowest  level  as  it  relates  to 
the  IDAT&L  Life  Cycle  Framework  Management  and  HSI: 


DODD5000.1 

LEVEL  I 

DODI  5000.02 

LEVEL  I 

CJCSI3170.01G 

LEVEL  1 

OPNAVINST  5310.23 

LEVEL  2 

SECNAVINST  5000.2D 

LEVEL  2 

VS  HSI  GUIDE  VOLUME  I 

LEVEL  3 

VS  HSI  GUIDE  VOLUME  II 

LEVEL  3 

NAVSEA  HSE  CODE  OF  BEST  PRACTICES 

LEVEL  3 
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C.  MODEL  BREAKDOWN 

Figures  2-4  are  a  depiction  of  the  model  used  for  the  gap  analysis,  broken  down 
by  color,  to  show  the  minimum  scope  of  responsibility  for  each  level  of  documentation.  It 
is  important  to  remember  that  this  breakdown  is  the  bare  minimum  that  must  be 
contained  in  each  document  in  order  to  establish  a  clear,  understandable,  and  efficient 
guide  to  practice  HSI  within  the  IDAT&L  Life  Cycle  Management  Framework. 

There  should  be  a  fair  amount  of  overlap  in  the  model  within  consecutive  levels. 
This  shows  that  the  information  contained  within  a  higher-level  document  is  being 
carried  out  by  the  next  lower  level.  The  idea  here  is  that  the  same  principles  that  are  put 
in  place  at  the  highest  level  are  still  valued  and  followed  throughout  all  levels  of 
documentation.  Level  1  criterion  is  marked  on  the  model  in  red.  Level  2  criteria  are 
marked  on  the  model  in  green.  Level  3  criteria  are  marked  on  the  model  in  blue. 

The  model  is  broken  up  into  three  separate  figures  to  make  it  easier  to  read.  The 
first  figure  (Figure  2)  is  the  policy  side  of  the  Ideal  Model.  Figure  3  is  the  operational 
side  of  the  model  that  spans  through  the  TD  Phase.  Figure  4  is  also  the  operational  side  of 
the  model  and  covers  the  remainder  of  the  life  cycle  through  OS  phase. 
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Figure  2.  The  Ideal  Model  (Policy  Side) 
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Figure  3.  The  Ideal  Model  (Operational  Side  through  TD) 
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D.  DOCUMENT  GAPS  AT  LEVEL  1 


1.  DoDD  5000.1 

Although  the  purpose  of  this  document  is  to  “provide  management  principles  and 
mandatory  policies  and  procedures  for  managing  all  acquisition  programs”  (DoD,  2003, 
p.  1  (a)),  this  document  fails  to  address  the  following  criteria  established  by  the  model, 
therefore  making  them  gaps  in  the  current  policy.  We  acknowledge  that  DoDI  5025.01 
constrains  the  length  of  DoD  Directives  to  eight  pages  and,  therefore,  would  limit  the 
amount  of  information  that  can  be  addressed,  but  we  feel  that  these  gaps  are  very 
important  to  successful  HSI  implementation.  We  have  included  the  portions  of  the  model 
that  pertain  to  each  level  to  allow  the  reader  to  visually  see  where  the  gaps  are  in  each 
level  on  the  model  for  this  specific  document.  The  boxes  that  have  a  yellow  outline/  dots 
around  them  are  the  gaps  we  have  identified.  Additionally,  the  gaps  are  also  listed  in 
bullet  format.  Figure  5  shows  the  gaps  in  the  policy  side  of  the  model  for  this  document. 
Figure  6  shows  the  gaps  in  the  operational  side  of  the  model  through  TD  for  this 
document.  Figure  7  shows  the  gaps  in  the  operational  side  of  the  model  through  OS  for 
this  document. 

•  Do  HSI 

•  Establish  Policy 

•  Participate  in  the  IDAT&L  Life  Cycle  Management  Framework 

•  Establish  HSI  reporting  authority 

•  Define  HSI  and  domains 

•  Identify  HSI  Key  Players  throughout  the  phases  of  the  Life  Cycle  (DoD) 

•  Materiel  Solutions  Analysis  Phase 

•  Technology  Development  Phase 

•  Engineering  and  Manufacturing  Development  Phase 

•  Production  and  Deployment  Phase 

•  Operations  and  Support  Phase 
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Figure  5.  Gaps  Identified  in  DoDD  5000.1  (Policy  Side) 
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Figure  6.  Gaps  Identified  in  DoDD  5000.1  (Operational  Side  through  TD) 
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Figure  7.  Gaps  Identified  in  DoDD  5000.1  (Operational  Side  through  OS) 
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As  noted  from  Chapter  III,  and  the  definitions  of  each  of  these  phase  items,  this 
document  misses  the  mark  on  all  requirements  for  this  level  of  documentation.  We  feel 
that  it  is  important  to  lay  a  strong,  solid,  and  well-defined  foundation  on  which  to  build. 
Although  this  document  does  mention  cost  and  affordability,  integrated  test  and 
evaluation,  interoperability,  safety,  systems  engineering,  technology  development  and 
transition,  and  total  systems  approach — all  of  which  are  essential  to  successfully 
implementing  HSI — it  neglects  to  lay  the  foundation  for  the  importance  of  HSI  within  the 
IDAT&L  Life  Cycle  Management  Framework.  Policy  is  mentioned  in  the  document; 
however,  it  merely  refers  to  the  Defense  Acquisition  System  as  a  whole,  and  does  not 
mention  HSI  as  part  of  that  system.  HSI  is,  however,  mentioned  as  part  of  a  total  system 
approach  that  the  PM  is  responsible  and  accountable  to  use,  but  no  guidance  is  given  as 
to  any  of  the  above  items  listed  as  gaps  in  the  document.  Overall,  this  document  needs 
massive  improvements  in  order  to  provide  the  necessary  information  to  successfully 
adapt  and  use  HSI  throughout  the  IDAT&L  Life  Cycle  Management  Framework. 

2.  DoDI  5000.02 

The  purpose  of  this  document  is  not  only  to  implement  DoDD  5000.1,  but  also  to 
“establish  a  simplified  and  flexible  management  framework  for  translating  capability 
needs  and  technology  opportunities,  based  on  approved  capability  needs,  into  stable, 
affordable,  and  well  managed  acquisition  programs”  (DoD,  2008,  p.  1).  This  document, 
along  with  the  other  two  documents  at  this  level,  should  serve  as  the  foundation  for  HSI 
to  build  on  during  the  IDAT&L  Life  Cycle  Management  Framework.  After  analyzing  this 
document,  the  items  below  are  noted  as  gaps  because  the  document  fails  to  make 
reference  to  them  in  its  current  standing.  We  have  included  the  portions  of  the  model  that 
pertain  to  each  level  to  allow  the  reader  to  visually  see  where  the  gaps  are  in  each  level 
on  the  model  for  this  specific  document.  The  boxes  that  have  a  yellow  outline  are  the 
gaps  we  have  identified.  Additionally,  the  gaps  are  also  listed  in  bullet  format.  Figure  8 
shows  the  gaps  in  the  policy  side  of  the  model  for  this  document.  Figure  9  shows  the  gaps 
in  the  operational  side  of  the  model  through  TD  for  this  document.  Figure  10  shows  the 
gaps  in  the  operational  side  of  the  model  through  OS  for  this  document. 
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Figure  8.  Gaps  Identified  in  DoDI  5000.02  (Policy  Side) 
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Figure  9.  Gaps  Identified  in  DoDI  5000.02  (Operational  Side  through  TD) 
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Figure  10.  Gaps  Identified  in  DoDI  5000.02  (Operational  Side  through  OS) 
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Based  on  the  definitions  provided  in  Chapter  III,  this  document  fails  to  adequately 
address  the  above  items.  DoDI  5000.02  places  a  heavy  emphasis  on  the  PM  for 
implementing  HSI  throughout  the  acquisition  process,  but  fails  to  identify  any  other 
specific  players.  The  document  makes  an  attempt  at  identifying  the  domains  of  HSI,  but 
neglects  to  define  HSI.  Other  items,  such  as  user  needs,  T&E,  cost  estimation,  and 
Systems  Engineering,  are  incorporated  into  the  document  to  provide  insight  and 
information  as  to  the  operation  of  these  items  within  the  acquisition  process.  The  mention 
of  these  items  does  not  negate  the  need  for  the  foundation  level  items  associated  with 
level  1  documentation. 

3.  CJCSI  3170.01F 

The  purpose  of  this  document  is  to  establish  the  policies  relating  to  the  JCIDS. 
This  document  also  serves  as  a  foundation  level  document  at  the  highest  level  of  the 
DoD’s  hierarchy.  After  reviewing  this  document,  we  concluded  that  the  following  gaps 
exist  within  the  document  as  it  is  currently  written.  We  have  included  the  portions  of  the 
model  that  pertain  to  each  level  to  allow  the  reader  to  visually  see  where  the  gaps  are  in 
each  level  on  the  model  for  this  specific  document.  The  boxes  that  have  a  yellow  outline 
are  the  gaps  we  have  identified.  Additionally,  the  gaps  are  also  listed  in  bullet  format. 
Figure  11  shows  the  gaps  in  the  policy  side  of  the  model  for  this  document.  Figure  12 
shows  the  gaps  in  the  operational  side  of  the  model  through  TD  for  this  document.  Figure 
13  shows  the  gaps  in  the  operational  side  of  the  model  through  OS  for  this  document. 

•  Do  HSI 

•  Establish  HSI  Policy 

•  Establish  HSI  reporting  authority 

•  Identify  HSI  Key  Players  throughout  the  phases  of  the  Life  Cycle  (DoD) 

•  Materiel  Solutions  Analysis  Phase 

•  Technology  Development  Phase 

•  Engineering  and  Manufacturing  Development  Phase 

•  Production  and  Deployment  Phase 

•  Operations  and  Support  Phase 
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Figure  12.  Gaps  Identified  in  CJCSI  3 170.0 IF  (Operational  Side  through  TD) 
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Although  this  document  misses  the  mark  according  the  model  on  level  1 
requirement,  it  does  establish  several  key  processes  that  must  take  place  in  order  to 
produce  capabilities  that  will  benefit  the  warfighter.  These  processes  include  the 
requirements  process,  the  acquisition  process,  and  the  planning,  programming,  budgeting 
and  execution  (PPBE)  process.  It  walks  through  the  entire  JCIDS  process,  beginning  with 
identifying  the  capabilities  necessary  to  perform  across  a  full  range  of  military  operations 
and  ending  with  the  JCIDS  document  review,  validation,  and  approval  process.  Between 
those  two  points,  document  relationships  are  addressed  including  the  ICD,  CDD,  and 
Capabilities  Production  Document  (CPD). 

Throughout  the  document,  simple  references  are  made  to  implementing  and  using 
HSI  in  the  JCIDS  process;  however,  the  references  are  vague  and  generally  require  a 
preliminary  understanding  of  HSI. 

4.  RECOMMENDATIONS  FOR  LEVEL  1  DOCUMENTS 

At  the  highest  level,  regardless  of  the  purpose  of  the  document,  the  act  of 
performing  HSI  must  be  established.  The  three  documents  listed  at  the  highest  level — 
DoDD  5000.1,  DoDI  5000.02,  and  CJCSI  3170. OIF —  have  different  purposes;  however, 
they  all  address  some  aspect  of  the  acquisition  process.  In  order  for  HSI  to  trickle  down 
through  the  levels  of  documentation,  the  actual  act  of  performing  HSI  must  be 
acknowledged  and  addressed  as  a  process,  rather  than  just  a  single  mention  that  HSI  shall 
be  conducted  by  the  PM.  As  mentioned  in  Chapter  III,  the  act  of  doing  HSI  is  defined  as 

...  the  process  of  conducting  Human  Systems  Integration  is  intended  to 
integrate  human  related  issues  into  the  development  of  the  product  by 
identifying  specific  human-related  and  mission-related  performance  and 
system  design  requirements,  communicating  those  requirements 
throughout  the  design  process,  and  ensuring  those  requirements  are  met 
(VS,  Vol.  2,  2005,  p.  12). 

This  process  is  essential  and  must  be  imbedded  at  the  highest  possible  level  to 
ensure  that  HSI  is  performed  with  continuity  throughout  the  Acquisition  Life  Cycle. 
Currently,  we  have  identified  that  this  gap  exists  within  both  DoDD  5000.1  and 
CJCSI  3 170. OIF.  We  recognize  that  DoDI  5000.02  addresses  the  mere  act  of  doing  HSI; 
however,  it  does  not  encompass  and  address  the  definition  provided  above.  If  kept  as  is, 
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the  definition  from  DoD  5000.02  must  also  be  included  in  the  other  two  documents 
named;  however,  that  situation  is  not  ideal.  Implementing  the  new  definition  of  the 
process  of  doing  HSI  in  all  three  documents  will  better  lay  the  foundation  for  continuity 
among  the  documents  and  provide  clear  guidance  for  lower-level  policy. 

We  acknowledge  that  all  three  documents  at  this  level  establish  policy  and 
guidance  with  respect  to  differing  parts  of  acquisition.  However,  none  of  the  documents 
attempt  to  establish  policy  directly  related  to  HSI,  which  is  why  a  gap  is  present  in  all  the 
documents.  HSI  policy  is  defined  as  a  planned  course  of  action  that  is  intended  to  be  used 
to  set  forth  guiding  principles  and  procedures  for  ensuring  that  HSI  is  properly  embedded 
throughout  the  entire  acquisition  strategy  to  produce  the  most  advantageous  products  to 
the  user  at  the  lowest  possible  cost.  The  policies  that  are  currently  set  forth  in  the 
documents  address  HSI  as  an  act  rather  than  a  process.  By  acknowledging  HSI  as  a 
process,  policy  can  easily  be  established  at  the  highest  level  to  ensure  implementation 
through  all  levels  of  documentation,  as  well  as  all  phases  of  the  Acquisition  Life  Cycle. 

DoDD  5000.1  has  a  gap  in  block  1.2,  denoted  as  “participate  in  the  IDAT&L  Life 
Cycle  Management  Framework.”  This  gap  is  not  present  in  the  other  two  documents  in 
level  1.  Based  on  that  fact,  it  is  not  necessary  to  implement  change  in  DoD  5000.1, 
however,  a  change  is  recommended.  Since  the  purpose  of  DoDD  5000.1  is  to  “provide 
management  principles  and  mandatory  policies  and  procedures  for  managing  all 
acquisition  programs,”  (DoD,  2003,  p.  1  (a))  it  is  difficult  to  effectively  make  that  claim 
without  addressing  participation  in  the  Life  Cycle  framework.  One  can  make  the 
assumption  of  participation;  however,  it  is  not  explicitly  stated. 

Based  on  our  model,  the  establishment  of  an  HSI  reporting  authority  is  critical  for 
oversight  of  HSI  in  the  acquisition  process.  The  CJCSI  3 170.0 IF  outlines  several  joint 
staff  directors  who  are  responsible  for  individual  domains;  however,  there  is  no 
integrative  structure  to  look  at  HSI  as  a  single  process,  rather  than  just  individual 
domains.  In  an  ideal  setting,  the  HSI  reporting  authority  should  be  implemented  as  a 
structure  to  ensure  an  open  line  of  communication  throughout  all  organizations  in  HSI 
and  the  acquisition  framework,  from  top  to  bottom,  to  effectively  track  and  report  on  all 
HSI-relevant  areas  and  provide  oversight  for  successful  program  acquisition.  This 
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authority  should  include  personnel  from  specific  services  as  the  primary  cornerstones  of 
the  authority,  and  be  supplemented  by  joint  figures  when  deemed  necessary  for  a  specific 
program.  The  domains  need  to  be  addressed  as  integrated  parts  of  the  process  to  allow 
trade-off  to  occur,  rather  than  being  addressed  individually.  In  order  for  HSI  to  be 
effective,  the  domains  cannot  exist  independently  from  one  other. 

Establishing  a  single  definition  for  HSI  is  imperative  for  allowing  this  process  to 
move  forward  and  be  fully  integrated  into  the  acquisition  process.  A  definition  gap  has 
been  identified  within  DoD  5000.1  and  DoD  5000.02.  A  definition  is  provided  for  HSI  in 
the  CJCSI  3 170.0 IF;  however,  the  definition  centers  on  an  outdated  document  (DoD 
5000.2,  2005)  and  the  individual  domains  that  make  up  HSI.  As  an  alternative,  we 
recommend  that  HSI  be  explicitly  defined  in  all  three  documents  as  an 

.  .  .  acknowledgement  that  the  human  is  a  critical  component  of  any 
complex  system.  It  is  an  interdisciplinary  approach  that  makes  explicit  the 
underlining  tradeoffs  across  the  HSI  domains,  facilitating  optimization  of 
total  system  performance.  (Miller  &  Shattuck,  2006,  p.  4) 

By  implementing  this  definition  at  the  highest  level  of  documentation,  we  feel 
confident  that  it  will  provide  clear  guidance  for  the  lower  levels.  It  will  also  set  the 
precedence  that  this  definition  must  be  followed  by  all  levels,  therefore  establishing 
continuity  across  all  levels.  In  addition  to  the  definition,  the  following  domains  must 
remain  as  cornerstones  of  the  HSI  process:  Manpower,  Personnel,  Training,  Safety, 
Occupational  Health,  Habitability,  Survivability,  Environment  and  Human  Factors 
Engineering.  CJCSI  3 170.0 IF  lists  the  domains  without  defining  them.  However,  DoDI 
5000.02  defines  the  domains  clearly  and  provides  explicit  deliverables.  These  domains 
and  definitions  must  be  updated  to  reflect  the  same  definition  and  description  of  domains 
in  each  document.  Currently,  DoDD  5000.1(2003)  does  not  address  domains  at  all. 

Just  as  establishing  a  common  definition  for  HSI  is  essential,  so  is  identifying  key 
players  throughout  the  phases  of  the  Life  Cycle.  Currently,  the  documentation  shows  a 
gap  in  all  three  documents  leveling  this  area.  It  is  recommended  that  key  players  be 
named  throughout  the  Life  Cycle  including  users,  stakeholders,  engineers,  managers,  etc. 
to  ensure  continuity  and  establish  a  solid  framework  for  conducting  HSI  activities 
throughout  the  process.  By  identifying  key  players  early  and  at  the  highest  level  of 
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documentation,  HSI  will  not  fall  by  the  wayside  at  various  stages  of  the  Life  Cycle.  In 
addition,  these  HSI  and  speeific  individuals  can  be  held  aecountable  for  deliverables 
involving  HSI  trade-offs.  These  players  must  be  established  in  at  least  one  of  the  three 
documents,  if  not  all  three,  to  clearly  identify  these  individuals  and  help  create  an  HSI 
reporting  strueture. 

DoDI  5000.02  clearly  defines  and  details  the  five  phases  of  the  aequisition 
proeess  (MSA,  TD,  EMD,  PD,  and  Operations  and  Support  (OS)),  however,  it  does  not 
fully  define  the  role  that  HSI  plays  within  those  phases.  By  using  the  reeommendations 
above,  elearly  defining  HSI,  establishing  HSI  policy,  and  recognizing  participation  in  the 
IDAT&L  Life  Cyele  management  framework,  it  is  imperative  that  these  definitions  must 
be  amended  to  inelude  the  specific  attributes  and  roles  that  HSI  praetitioners  play.  Onee 
these  definitions  are  amended,  they  must  be  earned  through  to  ensure  continuity 
throughout  the  Life  Cycle.  Neither  DoDD  5000.1  nor  CJCSI  3170. OIF  mention  or  define 
the  phases.  Beeause  DoDI  5000.02  is  fairly  thorough,  it  meets  the  minimum  requirement 
for  the  documents  at  this  level.  There  would  be  no  harm  in  implementing  them  in  the 
other  two  doeuments;  however,  implementation  is  not  neeessary. 

Overall,  the  level  1  documents  fail  to  meet  the  mark  on  many  key  points,  leaving 
many  gaps  aecording  to  the  model;  however,  the  ehanges  that  are  required  to  lay  a  solid 
foundation  and  amend  the  documents  to  fill  the  gaps  are  reasonable  and  will  provide 
concrete  footing  for  HSI  in  the  acquisition  world. 

E.  DOCUMENT  GAPS  AT  LEVEL  2 
1.  OPNAVINST  5310.23 

The  purpose  of  this  instruction  is  to  address  HSI  throughout  the  Navy.  It  was 
established  through  the  Offiee  of  the  Chief  of  Naval  Operations  and  is  the  Navy’s 
overarehing  documentation  on  how  HSI  should  be  struetured  in  the  Navy.  As  of 
January  2009,  this  poliey  has  not  been  offieially  signed,  so  it  is  still  eonsidered  in  draft 
form.  Analysis  of  this  doeumentation  identified  the  following  gaps.  We  have  ineluded  the 
portions  of  the  model  that  pertain  to  each  level  to  allow  the  reader  to  visually  see  where 
the  gaps  are  in  eaeh  level  on  the  model  for  this  speeific  document.  The  boxes  that  have  a 
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yellow  outline  are  the  gaps  we  have  identified.  Additionally,  the  gaps  are  also  listed  in 
bullet  format.  Figure  14  shows  the  gaps  in  the  policy  side  of  the  model  for  this  document. 
Figure  15  shows  the  gaps  in  the  operational  side  of  the  model  through  TD  for  this 
document.  Figure  16  shows  the  gaps  in  the  operational  side  of  the  model  through  OS  for 
this  document. 


•  Define  HSI  and  Domains 

•  Operational  Reporting  Authority 

•  Administrative  Reporting  Authority 

•  Identify  Roles/Key  Players  in  Operational  Reporting  Authority 

•  Identify  Roles/Key  Players  in  Administrative  Reporting  Authority 

•  Identify  Key  Organizations  throughout  the  Life  Cycle  at  the  Service  Level 
(Operational) 

•  Identify  Key  Organizations  throughout  the  Life  Cycle  at  the  Service  Level 
(Administrative) 

•  Apply  Defined  HSI  Domains 

•  Ensure  Integration  of  Domains 

•  Identify  HSI  Key  Players  throughout  the  Phases  of  the  Life  Cycle 

•  Technology  Development  Phase 

•  Transition  from  Technology  Development  Phase  to  Engineering  and 
Manufacturing  Development  Phase 

•  Engineering  and  Manufacturing  Development  Phase 

•  Transition  from  Engineering  and  Manufacturing  Development  Phase  to 

Production  and  Deployment  Phase 

•  Production  and  Deployment  Phase 

•  Operations  and  Support  Phase 
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Figure  14.  Gaps  Identified  in  OPNAVINST  53 10.23  (Policy  Side) 
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Figure  15.  Gaps  Identified  in  OPNAVINST  53 10.23  (Operational  Side  through  TD) 
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Figure  16.  Gaps  Identified  in  OPNAVINST  5310.23  (Operational  Side  through  OS) 
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2. 


SECNAVINST  5000.2D 


The  main  purpose  of  SECNAVINST  5000. 2D  is  to  give  the  Navy  guidance  on 
how  to  merge  the  JCIDS  and  the  acquisition  process.  This  document  includes  chapters  on 
systems  engineering  and  HSI.  After  reviewing  this  instruction,  the  following  items  are 
identified  as  gaps  within  our  model.  We  have  included  the  portions  of  the  model  that 
pertain  to  each  level  to  allow  the  reader  to  visually  see  where  the  gaps  are  in  each  level 
on  the  model  for  this  specific  document.  The  boxes  that  have  a  yellow  outline  are  the 
gaps  we  have  identified.  Additionally,  the  gaps  are  also  listed  in  bullet  format.  Figure  17 
shows  the  gaps  in  the  policy  side  of  the  model  for  this  document.  Figure  18  shows  the 
gaps  in  the  operational  side  of  the  model  through  TD  for  this  document.  Figure  19  shows 
the  gaps  in  the  operational  side  of  the  model  through  OS  for  this  document. 

•  Define  HSI  and  Domains 

•  Operational  Reporting  Authority 

•  Administrative  Reporting  Authority 

•  Identify  Roles/Key  Player  in  Operational  Reporting  Authority 

•  Identify  Roles/Key  Players  in  Administrative  Reporting  Authority 

•  Identify  Key  Organizations  throughout  the  Life  Cycle  at  the  Service  Level 
(Operational) 

•  Identify  Key  Organizations  throughout  the  Life  Cycle  at  the  Service  Level 
(Administrative) 

•  Apply  Defined  HSI  Domains 

•  Ensure  Integrations  of  Domains 

•  Identify  HSI  Key  Players  throughout  the  Phases  of  the  Life  Cycle 

•  Transition  Criteria  from  JCIDS  to  Materiel  Solutions  Phase 

•  Materiel  Solutions  Analysis  Phase 

•  Transition  Criteria  from  Materiel  Solutions  Phase  to  Technology 
Development  Phase 

•  Technology  Development  Phase 

•  Transition  Criteria  from  Technology  Development  Phase  to  Engineering 

and  Manufacturing  Development  Phase 
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•  Engineering  and  Manufacturing  Development  Phase 

•  Transition  Criteria  from  Engineering  and  Manufacturing  Development 
Phase  to  Production  and  Deployment  Phase 

•  Production  and  Deployment  Phase 

•  Operations  and  Support  Phase 
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Gaps  Identified  in  SECNAVINST  5000.2D  (Policy  Side) 
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Figure  18.  Gaps  Identified  in  SECNAVINST  5000.2D  (Operational  Side  through  TD) 
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1.2.1. 6.1 
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Figure  19.  Gaps  Identified  in  SECNAVINST  5000.2D  (Operational  Side  through  TD) 
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3. 


RECOMMENDATIONS  FOR  LEVEL  2  DOCUMENTS 


Our  model  was  developed  to  ensure  that  all  the  policy  and  guidance  flows  from 
the  highest  levels  of  documentation  down  to  the  lowest  levels.  This  means  policy  that 
was  stated  previously  at  the  highest  level,  must  also  be  included  at  the  lowest  levels. 
Therefore,  the  reader  will  note  that  we  state  “recommendation  referred  to  at  the  highest 
level.”  By  this,  we  are  trying  to  avoid  restating  the  recommendations  previously  given. 

Having  a  single  definition  and  list  of  HSI  domains  is  imperative  for  the  initial 
steps  of  unifying  the  HSI  and  acquisition  process.  Without  a  single,  common  definition 
throughout  all  of  the  DoD  and  DoN  policies,  the  meaning  and  purpose  of  HSI  will  be 
interpreted  differently  by  each  user.  There  is  a  gap  in  both  OPNAVINST  5310.23  and 
SECNAVINST  5000. 2D,  with  respect  to  the  definition  of  HSI  and  the  domains.  The 
recommendation  to  close  the  gap  was  referenced  above  in  the  Level  1  documentation. 

Having  a  reporting  authority  for  both  the  operational  and  administrative  chain  of 
commands  is  imperative.  These  are  two  distinct  functions  of  our  military  that  need  to 
have  people  informed  of  the  HSI  process  within  their  offices.  We  have  noted  a  gap  for 
both  documents  and  recommend  that  someone  be  appointed  as  the  HSI  Operational 
Reporting  Authority,  along  with  the  HSI  Administrative  Reporting  Authority,  to  ensure 
that  information  from  all  areas  of  HSI  is  being  reported  to  the  overall  HSI  Reporting 
Authority.  See  Figure  20  for  visual  breakdown.  Level  1  criterion  is  marked  on  the  model 
in  red.  Level  2  criteria  are  marked  on  the  model  in  green.  Level  3  criteria  are  marked  on 
the  model  in  blue. 
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Figure  20.  The  Ideal  Model  (Policy  Side) 


Along  with  a  reporting  authority  designated  for  the  operational  and  administrative 
chains  of  command,  HSI  roles  and  key  players  must  be  identified.  Without  the 
identification  of  specific  roles  and  key  players,  HSI  cannot  be  effectively  completed 
within  the  acquisition  process.  To  ensure  the  effective  completion  of  HSI  throughout  the 
entire  acquisitions  process,  we  recommend  that  these  roles  and  key  players  be  identified. 

Having  a  single  HSI  definition  and  list  of  domains  satisfies  the  requirements  for 
the  highest  level  of  documentation,  but  we  realize  that  at  the  lower  levels  there  must  be 
more  direction.  Currently,  there  is  a  gap  within  both  documents  at  this  level.  To 
effectively  accomplish  HSI  in  the  acquisition  Life  Cycle,  the  application  and  integration 
of  the  definition  and  domains  must  be  present.  For  example,  if  an  acquisition  program  has 
multiple  services,  a  common  set  of  domains  and  definitions  are  essential,  as  each  service 
emphasizes  different  domains,  as  noted  in  Chapter  I. 


HSI  Key  Players  throughout  the  Phases  of  the  Life  Cycle  recommendations  are 
identified  in  Level  1 . 

The  recommendations  of  the  different  phases  can  be  found  in  Level  1 . 

The  OPNAVINST  5310.32  is  strictly  geared  towards  the  JCIDS  process  and  HSI 
within  that  process.  Therefore,  there  are  gaps  that  can  be  found  from  the  lack  of  direction 
for  the  Transition  Criteria  from  Materiel  Solutions  Analysis  Phase  to  Technology 
Development  Phase,  the  Transition  Criteria  from  Technology  Development  Phase  to 
Engineering  and  Manufacturing  Development  Phase,  and  the  Transition  Criteria  from 
Engineering  and  Manufacturing  Development  Phase.  Each  of  these  transitions  must  be 
addressed  to  ensure  that  HSI  is  being  done  throughout  the  entire  Acquisition  Life  Cycle. 
The  SECNAVINST  states  that  “the  PM  and  sponsors  shall  address  HSI  throughout  all  the 
phases  of  the  acquisition  process”  (DoN,  2008,  p.  12  (b)).  The  simple  wording  of  “shall” 
means  that  this  is  required  to  be  addressed,  but  not  necessarily  documented.  In  order  to 
optimize  the  effects  of  our  systems,  HSI  must  and  should  be  addressed  and  documented 
throughout  all  of  the  phases.  Wording  can  seem  mundane,  but  the  effects  of  a  single  word 
can  mean  not  having  to  do  a  portion  of  what  should  be  required. 

As  a  whole,  the  Level  2  documents  seemed  to  be  laid  out  in  such  a  way  as  to 
properly  facilitate  the  use  and  management  of  HSI.  However,  there  are  still  many  gaps 
that  can  be  fixed  to  optimize  the  effects  HSI  can  have  on  a  program. 

F.  DOCUMENT  GAPS  AT  LEVEL  3 

1.  Virtual  SYSCOM  Human  Systems  Integration  Guide,  Volumes  1  and 
2 

This  document  was  established  by  the  Virtual  SYSCOM  in  2005.  Their  purpose  is 
to  unify  the  practices  and  methods  used  within  the  different  SYSCOM  to  develop  and 
integrate  HSI  to  the  Life  Cycle.  We  have  included  the  portions  of  the  model  that  pertain 
to  each  level  to  allow  the  reader  to  visually  see  where  the  gaps  are  in  each  level  on  the 
model  for  this  specific  document.  The  boxes  that  have  a  yellow  outline  are  the  gaps  we 
have  identified.  Additionally,  the  gaps  are  also  listed  in  bullet  format.  Figure  21  shows 
the  gaps  in  the  policy  side  of  the  model  for  this  document.  Figure  22  shows  the  gaps  in 
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the  operational  side  of  the  model  through  TD  for  this  doeument.  Figure  23  shows  the 
gaps  in  the  operational  side  of  the  model  through  OS  for  this  doeument. 

•  Establish  HSI  Reporting  Authority 

•  Operational  Reporting  Authority 

•  Administrative  Reporting  Authority 

•  Identify  Roles/Key  Players  in  Operational  Reporting  Authority 

•  Identify  Role/Key  Players  in  Administrative  Reporting  Authority 

•  Identify  HSI  Key  Organizations  throughout  Life  Cyele  at  the  Command 
Level  (Operational) 

•  Identify  HSI  Key  Organizations  throughout  Life  Cyele  at  the  Command 
Level  (Reporting) 

•  Identify  HSI  Key  Players  throughout  the  Phases  of  the  Life  Cyele 

•  Acknowledgement  of  Materiel  Solution 

•  Name  Materiel  Solution  Manager 

•  Materiel  Development  Decision 

•  User  Input/Feedback  (MSA) 

•  Draft  KPPs 

•  PDR 

•  KPPs  (TD) 

•  User  Input/Feedback  (TD) 

•  Name  Program  Manager 

•  KPPs  (EMD) 

•  Post-  PDR  Assessment 

•  Post-  CDR  Assessment 

•  Integrated  System  Design 

•  CDR 

•  User  Input/Feedback  (EMD) 

•  Developmental  Test  and  Evaluation 

•  User  Input/Feedback;  (PD) 
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•  Operational  Readiness  Assessment 

•  Implement  Maintenance  Objectives  (PD) 

•  Implement  Training  Plan 

•  Life  Cycle  Sustainment 

•  User  Input/Feedback  (OS) 

•  Document  Lessons  Learned 

•  HSI  Action  Plan 

•  Implement  Maintenance  Objectives  (OS) 
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1.1. 1.1. 1.1.1  1.1. 1.2.1. 1.1 


Figure  2 1 .  Gaps  Identified  in  VS  HSI  Guide  Vols.  I  and  II  (Poliey  Side) 
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Figure  22.  Gaps  Identified  in  VS  HSI  Guide  Vols.  I  and  II  (Operational  Side  through  TD) 
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1.2.1. 7.1 


Figure  23.  Gaps  Identified  in  VS  HSI  Guide  Vols.  I  and  II  (Operational  Side  through  OS) 
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2. 


NAVSEA  HSE  Best  Practices  Guide 


This  document  was  established  by  NAVSEA  in  2009.  The  purpose  is  to  unify  the 
practices  and  methods  used  within  the  NAVSEA  to  develop  and  integrate  HSI  within 
systems  engineering  and  the  Life  Cycle.  We  have  included  the  portions  of  the  model  that 
pertain  to  each  level  to  allow  the  reader  to  visually  see  where  the  gaps  are  in  each  level 
on  the  model  for  this  specific  document.  The  boxes  that  have  a  yellow  outline  are  the 
gaps  we  have  identified.  Additionally,  the  gaps  are  also  listed  in  bullet  format.  Figure  24 
shows  the  gaps  in  the  policy  side  of  the  model  for  this  document.  Figure  25  shows  the 
gaps  in  the  operational  side  of  the  model  through  TD  for  this  document.  Figure  26  shows 
the  gaps  in  the  operational  side  of  the  model  through  OS  for  this  document. 

•  Establish  Policy 

•  Establish  HSI  Reporting  Authority 

•  Define  HSI  and  Domains 

•  Operational  Reporting  Authority 

•  Administrative  Reporting  Authority 

•  Identify  Roles/Key  Players  in  Operational  Reporting  Authority 

•  Identify  Roles/Key  Players  in  Administrative  Reporting  Authority 

•  Identify  Key  Players  throughout  the  Phases  of  the  Life  Cycle 

•  Test  and  Evaluation  Strategy 

•  Name  Materiel  Solution  Manager 

•  User/Input  Feedback  (MSA) 

•  Preliminary  System  Specification 

•  Draft  KPPs 

•  Information  Support  Plan  (TD) 

•  Footprint  Reduction 

•  Proposed  Training  Systems  Plan 

•  System  Performance  Specification  (TD) 

•  Technology  Readiness  Assessment 

•  PDR 
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•  Acquisition  Strategy 

•  KPPs  (TD) 

•  Integrated  Baseline  Review 

•  User  Input/Feedback 

•  System  Support  and  Maintenance  Objectives 

•  Program  Protection  Plan 

•  Milestone  Exit  Criteria  (Milestone  B) 

•  Name  PM 

•  Information  Support  Plan  (EMD) 

•  Approved  Training  Systems  Plan 

•  KPPs  (EMD) 

•  Initial  Product  Baseline 

•  Post-  PDR  Assessment 

•  Post-  CDR  Assessment 

•  Product  Support  Package  (EMD) 

•  CDR 

•  Configuration  Items  Component  -  Level  Specification 

•  User  Input/Feedback  (EMD) 

•  Milestone  Exit  Criteria  (Milestone  C) 

•  Production  Baseline 

•  Product  Support  Package  (PD) 

•  PESHE  (PD) 

•  Cost  and  Manpower  Estimate  (PD) 

•  User  Input/Feedback  (PD) 

•  Operational  Readiness  Assessment  (PD) 

•  Implement  Maintenance  Objectives  (PD) 

•  Implement  Training  Plan 

•  In-service  Review  Data 

•  Cost  and  Manpower  Summary 
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•  Product  Support  Package  (OS) 

•  Inputs  to  ODD  (Next  Increment) 

•  New  Program  Initiation 

•  Life  Cycle  Sustainment 

•  Disposal  Plan 

•  PESHE  (OS) 

•  Revised  Training  Systems  Plan  (for  upgrades/next  increment) 

•  Operational  Readiness  Assessment  (OS) 

•  Implement  Maintenance  Objectives  (OS) 


Do  HSI 
Do  HSI 

1.0 


1.1. 1.1. 1.1.1  1.1. 1.2.1. 1.1 


Figure  24.  Gaps  Identified  in  NAVSEA  HSE  Best  Practices  Guide  (Policy  Side) 
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Figure  25.  Gaps  Identified  in  NAVSEA  HSE  Best  Practices  Guide  (Operational  Side  through  TD) 
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Transition  from  EMDto 

Production  and 

PD  (Milestone  C) 

Deployment  (PD)  Phase 

1.2.1. 7 

1.2.1. 8 

User  Input  /  Feedback 


Specifications  for  System 
Modifications  /  Upgrades 


Document  lessons 
Learned 


1.2.1.9.1 


Figure  26.  Gaps  Identified  in  NAVSEA  HSE  Best  Praetices  Guide  (Operational  Side  through  OS) 
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3. 


Recommendations  for  Level  3  Documents 


The  Virtual  SYSCOM’S  Human  Systems  Integration  Guide,  Volumes  1  and  2  and 
NAVSEA’s  HSE  Best  Practices  Guide  are  unique  documents  in  our  analysis.  They 
cannot  be  considered  true  policy  for  the  Navy,  but  rather  are  guidance  documents  that 
were  created  as  a  reference  for  those  participating  in  HSI  activities  throughout  the  Navy. 
With  this  in  mind,  in  some  instances,  we  have  recommendations  that  were  not  originally 
intended  for  these  documents,  due  to  changes  and  revisions  within  the  entire  HSI  process. 

The  recommendations  for  the  following  were  previously  stated  and  in  Levels  1 
and  2  recommendations.  Establish  HSI  Reporting  Authority,  Define  HSI  and  Domains, 
Operational  Reporting  Authority,  Administrative  Reporting  Authority,  Identify 
Roles/Key  Players  in  Operational  Reporting  Authority,  Identify  Roles/Key  Players  in 
Administrative  Reporting  Authority,  and  Identify  Key  Players  throughout  the  Phases  of 
the  Life  Cycle. 

A  gap  that  has  been  noted  within  the  Virtual  SYSCOM  HSI  Guide,  Volumes  1  and 
2,  is  the  lack  of  acknowledgement  of  a  materiel  solution.  This  can  be  attributed  to  the  fact 
that  this  guide  is  somewhat  outdated  and  does  not  contain  the  changes  that  have  been 
made  to  the  Life  Cycle,  to  include  phase  changes  that  are  documented  in  DoDI  5000.02. 
Regardless,  there  must  be  an  acknowledgment  of  the  materiel  solution  in  order  to  move 
through  the  Life  Cycle.  An  HSI  practitioner  should  be  involved  in  this  process  to  ensure 
that  HSI  is  being  considered  from  the  start  of  the  program. 

The  Preliminary  System  Specification  was  not  addressed  by  the  HSE  Best 
Practices  Guide.  This  step,  along  with  the  revisions  of  the  System  Specification,  which 
will  be  discussed  later,  is  a  very  important  aspect  of  the  acquisition  of  a  system. 
Everything  that  is  considered  in  this  step,  must  have  an  HSI  practitioner  to  oversee  the 
parameters  that  are  discussed. 

A  T&E  strategy  is  critical  from  the  start  of  the  design  of  the  system.  Along  with 
the  establishment  of  a  T&E  strategy,  an  HSI  practitioner  should  be  involved  with  the 
entire  T&E  process,  including  the  developmental  and  operational  testing  of  the  program, 
to  ensure  that  all  domains  are  being  carefully  tested.  A  gap  is  present  in  the  HSE  Best 
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Practices  Guide  and  it  is  therefore  recommended  that  HSI  be  fully  integrated  with  the 
development  of  a  T&E  strategy  early  in  the  Life  Cycle. 

A  significant  gap  that  we  found  within  our  analysis  is  the  PM  being  the  position 
that  is  in  charge  of  HSI.  We  have  stated  throughout  our  research  that  it  is  imperative  to 
have  HSI  throughout  the  entire  acquisition  Life  Cycle.  If  the  PM  is  the  person  in  charge 
of  overseeing  HSI,  then  there  is  a  gap  until  the  PM  is  named  after  Milestone  B.  This 
means  that  there  is  no  position  that  oversees  HSI  within  that  program  for  most  of  the 
beginning  of  the  acquisition  process.  Therefore,  we  recommend  that  a  Materiel  Solution 
Manager  be  named  after  a  materiel  solution  has  been  identified.  This  person  will  oversee 
HSI  until  the  PM  is  named  and  is  fully  briefed  on  what  has  been  occurring  throughout  the 
program  up  to  that  point.  The  Materiel  Solution  Manager  can  be  seen  somewhat  as  an 
Executive  Officer,  who  will  be  responsible  for  the  HSI  portions  until  the  PM  comes 
onboard  and  is  fully  briefed.  This  ensures  that  there  is  a  “chain  of  command,”  or  a 
position  of  authority,  on  documentation  and  any  recommendations  that  need  to  be  made 
with  regard  to  HSI  prior  to  the  involvement  of  the  PM. 

To  ensure  that  the  user  is  involved  with  the  acquisition  process,  we  have 
implemented  a  User  Input/Feedback  loop  into  each  phase  of  the  Life  Cycle.  Having  the 
input  of  the  user  is  imperative  and  would  greatly  increase  the  effectiveness  of  how  the 
program  is  carried  out.  Therefore,  we  have  identified  gaps  in  both  documents  where  the 
documents  do  not  adequately  involve  the  user  for  helpful  feedback.  For  each  phase  that 
has  a  gap  identified,  we  recommend  a  formal  process  of  some  sort  to  allow  the  user  to 
give  feedback  to  the  key  players  for  the  program.  There  must  be  an  HSI  practitioner 
present  at  these  feedback  sessions  to  gain  knowledge,  suggest  information,  and  handle 
any  problems  related  to  HSI. 

Draft  KPPs  and  KPPs  are  very  important  to  the  Acquisition  Life  Cycle.  The 
continuous  development  of  KPPs  throughout  the  different  phases  is  imperative  for  the 
development  and  production  of  the  system.  HSI  practitioners  must  be  involved  in  the 
development  of  KPPs  from  the  draft  throughout  the  entire  process. 
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The  Information  Support  Plan,  Footprint  Reduction,  System  Performance 
Specification,  Technology  Readiness  Assessment,  Acquisition  Strategy,  Integrated 
Baseline  Review,  and  Program  Protection  Plan  are  all  important  parts  of  the  Technology 
Development  Phase.  Each  of  these  is  integral  in  the  successful  acquisition  of  a  system 
and  must  have  an  HSI  practitioner  involved  to  ensure  that  the  program  is  considering  all 
the  domains  of  HSI.  The  Best  Practices  Guide  does  not  fully  incorporate  the  importance 
of  HSI  and  these  key  activities  within  the  acquisition  process.  As  stated  previously,  “the 
PDR  will  inform  requirement  trades;  improve  cost  estimation;  and  identify  remaining 
design,  integration,  and  manufacturing  risk”  (DoD  5000.02,  2008,  p.  19).  We 
acknowledge  that  the  documents  at  this  level  have  not  been  updated  to  include  the  new 
changes  that  have  been  made  to  DoD  5000.02.  Yet,  we  want  to  make  clear  that  it  is 
imperative  to  have  an  HSI  practitioner  involved  in  the  development  of  the  PDR. 

The  HSE  Best  Practices  Guide  does  not  fully  address  the  importance  of  HSI  at  the 
Milestone  Exit  Criteria.  The  criteria  allow  programs  to  proceed  into  the  next  phase  of  the 
acquisition  process.  If  the  Milestone  Exit  Criteria  are  not  met,  the  program  will  not 
proceed.  The  HSI  trade-offs  and  domains  must  be  examined  during  these  Milestone 
reviews.  Therefore,  an  HSI  practitioner  must  be  involved  in  the  discussions  or 
considerations  for  the  next  phase. 

The  Post-PDR  Assessment  is  an  “assessment  conducted  by  the  PM  and  Milestone 
Decision  Authority  to  ensure  that  the  PDR  report  reflects  any  requirements  trades  based 
on  the  assessment  of  cost,  schedule  and  performance  risk”  (DoD,  2008,  p.  21).  The  Post- 
CDR  Assessment  is  an  assessment  of  “design  maturity  as  evidenced  by  measures  such  as: 
successful  completion  of  sub-system  CDRs;  the  percentage  of  hardware  and  software 
product  build-to  specifications  and  drawings  completed  and  under  configuration 
management...”  (DoD,  2008,  p.  21).  None  of  these  new  additions  has  been  added  to  any 
of  the  documents  at  this  level. 

The  Integrated  System  Design  ensures  that  each  HSI  need  and  constraint  is 
managed  throughout  the  entire  Life  Cycle.  The  need  for  having  an  HSI  practitioner 
involved  in  the  Integrated  System  Design  is  obvious.  Each  document  must  contain 
information  about  the  program  having  an  Integrated  System  Design. 
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The  CDR,  PDR,and  post-assessment  aetivities  have  not  been  updated  in  either  the 
Virtual  SYSCOM  HSI  Guide  or  the  HSE  Best  Practices  Guide,  therefore,  we  recommend 
that  these  documents  be  updated  to  contain  the  CDR  and  to  include  an  HSI  practitioner  in 
the  future. 

To  plan  and  develop  a  program  that  will  create  a  successful  system,  many  items 
must  be  taken  into  consideration.  One  item  of  great  importance  is  a  maintenance  plan. 
This  cannot  be  developed  at  the  end  of  the  Acquisition  Life  Cycle,  but  it  must  be  done  in 
the  beginning  to  ensure  that  maintenance  aspects  are  considered  while  it  is  still  cost 
effective  to  do  trade-offs.  Having  the  maintenance  practitioners  involved  with  the  process 
is  essential.  When  the  maintenance  practitioners  are  developing  their  maintenance 
manuals,  HSI  practitioners  must  be  involved  in  learning  and  developing  effective 
maintenance  techniques  and  to  be  able  to  design  a  system  that  will  allow  for  minimal 
maintenance.  If  HSI  is  not  involved  until  after  the  manuals  are  written,  it  is  too  late. 
Although  the  documents  discuss  maintenance  plans,  they  do  not  effectively  integrate  the 
maintenance  practitioners  and  the  HSI  practitioners  throughout  the  entire  Life  Cycle. 

Training  plans  are  just  as  important  as  maintenance  plans.  As  stated  above,  the 
training  practitioners  and  HSI  practitioners  should  work  hand-in-hand  throughout  each 
phase  of  the  Life  Cycle  to  develop  training  programs  and  training  systems  that  enhance 
system  performance.  The  documents  touch  on  training,  but  do  not  provide  enough 
guidance  to  either  training  or  HSI  practioners.  In  many  of  the  previous  acquisition 
programs,  HSI  lessons  learned  were  rarely  documented. 

The  Operational  Readiness  Assessment  is  another  part  of  the  acquisition  process 
that  must  include  HSI  involvement.  As  the  Operational  Readiness  Assessment  is  updated, 
the  HSI  practitioner  should  be  a  participant  in  determining  readiness  and  making  any 
suggestions  that  would  benefit  the  program. 

Many  items  must  be  completed,  reviewed,  and  discussed  throughout  the 
Engineering  and  Manufacturing  Development  Phase.  Some  of  the  specific  requirements 
during  this  phase  that  were  not  discussed  in  the  HSE  Best  Practices  Guide  include: 
Information  Support  Plan,  Initial  Product  Baseline,  Product  Support  Package,  and 
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Configuration  Items  Component — Level  Specification.  These  are  all  required  for  this 
phase;  having  an  HSI  practitioner  involved  will  enhance  the  design  and  production  of 
the  system. 

Our  model  has  a  reduced  HSI  requirement  for  the  Production  and  Deployment 
Phase,  but  this  does  not  mean  that  HSI  should  not  be  considered  throughout  this  phase. 
The  HSE  Best  Practices  Guide  must  include  the  continuation  of  HSI  practitioners 
participating  in  the  following  gaps:  Production  Baseline,  Product  Support  Package, 
PESHE,  Cost  and  Manpower  Estimate,  and  Operational  Readiness  Assessment.  These  are 
all  critical  to  the  continuing  development  of  HSI  throughout  the  entire  Life  Cycle. 

The  Operations  and  Support  Phase,  just  as  the  Production  and  Deployment  Phase, 
has  often  left  out  HSI  practitioners.  Many  HSI  considerations  are  imperative  for  the 
successful  deployment  of  a  system.  The  HSE  Best  Practices  Guide  contains  gaps  in 
addressing  HSI  in  the  following  criteria  required  for  the  Operations  and  Support  Phase: 
In-Service  Review  Data,  Cost  and  Manpower  Summary,  Product  Support  Package  Inputs 
to  CDD  (Next  Increment),  New  Program  Initiation,  Life  Cycle  Sustainment,  Disposal 
Plan,  and  PESHE.  Each  of  these  must  be  addressed  to  ensure  that  HSI  is  performed 
throughout  the  entire  Life  Cycle  and  to  ensure  the  effectiveness  of  the  system. 

Overall,  level  3  was  difficult  to  analyze  because  of  the  differences  between  the 
two  documents.  The  Virtual  SYSCOM  HSI  Guide  and  the  HSE  Best  Practices  Guide  are 
very  informative  with  regard  to  HSI  and  have  established  an  excellent  baseline  of 
information  for  those  currently  doing  HSI.  If  the  gaps  that  we  have  identified  are 
addressed,  each  of  these  documents  will  enhance  our  acquisition  of  systems,  with  respect 
to  HSI. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  OVERVIEW 

Based  on  the  gaps  and  recommendations  derived  from  the  gap  analysis  performed 
in  Chapter  IV,  this  chapter  addresses  major  areas  for  immediate  change  within  the  Navy 
and  proposes  alternative  solutions  to  enhance  overall  HSI  continuity  and  effectiveness 
across  the  acquisition  framework.  Recommendations  for  areas  of  future  study  in  the  field 
of  HSI  will  also  be  made. 

B.  CONCLUSIONS 

The  DoD  and  Level  1  documentation  do  not  appear  to  possess  policies  or 
effective  procedures  to  systematically  integrate  HSI  into  the  materiel  acquisition  process. 
To  date,  the  DoD  and  DoN  have  not  established  adequate  policies  or  procedures  for  the 
application,  execution,  support,  and  integration  of  HSI  into  the  acquisition  framework 
and  Life  Cycle.  To  achieve  information  exchange  and  adequate  guidance  in  the  field  of 
HSI,  the  Navy  relies  on  piecemeal  documentation  and  expertise  within  its  SYSCOMs. 

These  current  practices  fail  to  achieve  the  benefits  gained  by  using  an  integrated 
and  comprehensive  approach  to  ensure  that  appropriate  documentation  and  guidance  are 
set  for  each  level.  Consequently,  the  Navy  is  failing  to  optimize  total  system 
performance,  with  respect  to  the  human,  in  the  acquisition  Life  Cycle. 

The  effectiveness  of  the  Navy’s  HSI  Program  is  driven  by  the  operational 
expertise  and  acquisition  experience  at  the  SYSCOM  level.  Limited  guidance,  and 
nonstandardized  HSI  policies  and  procedures,  force  the  SYSCOM-level  commands  to 
rely  on  the  HSI  knowledge  they  have  in-house  to  successfully  establish  and  execute  HSI 
efforts.  Without  standardized  HSI  policies  and  procedures,  the  Navy  relies  on  the 
personnel  in  HSI  billets  and  roles  to  establish  and  execute  HSI  efforts.  This  practice 
results  in  inconsistent  application,  performance,  and  support  among  programs — with 
regard  to  HSI — as  well  as  creating  a  large  variability  between  programs  within  the  same 
or  similar  acquisition  categories. 
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The  consequences  of  this  variability  can  be  lessened  by  changing  the 
organizational  culture  and  providing  adequate  guidance  throughout  the  Acquisition  Life 
Cycle.  By  empowering  more  than  just  the  PM  to  do  HSI,  there  will  be  better 
communication  and  effectiveness  of  managing  HSI-related  concerns  throughout  the 
entire  acquisition  effort. 

Current  HSI  policy  and  practices  in  the  Navy  do  not  involve  the  system  user 
enough  in  the  acquisition  and  decision-making  processes.  The  user  is  granted  limited 
visibility  and  feedback  opportunities  throughout  the  acquisition  process._Currently,  there 
are  only  three  places  throughout  the  Life  Cycle  when  the  user  may  have  visibility, 
depending  on  the  discretion  of  the  PM.  This  current  system  does  not  allow  the  user  to 
effectively  influence  system  design  with  regard  to  human  considerations.  Rather,  it 
clouds  the  understanding  of  HSI  roles  and  responsibilities. 

By  using  the  model  created  for  this  thesis,  the  current  policies  and  practices  were 
assessed  and  found  to  be  inadequate.  Human-related  issues  are  often  not  raised, 
documented,  tracked  by  an  audit  trail,  or  assessed  by  HSI  specialists.  These  gaps  in 
documentation  lead  to  the  breakdown  of  HSI  throughout  the  IDAT&L  Life  Cycle 
Management  Framework,  and  make  it  extremely  difficult  to  review  the  effectiveness  of 
the  HSI  decision-making  process  regarding  the  program’s  status. 

The  successful  implementation  of  HSI  into  the  acquisition  process  throughout  the 
entire  Life  Cycle  must  be  founded  on  the  basis  of  senior  DoD  and  Navy  officials.  To 
achieve  service-wide  implementation  of  HSI,  the  DoD  and  Navy  must  rely  on  a  top-down 
management  approach  and  the  buy-in  of  senior  Navy  officials  in  order  to  institute  and 
sustain  an  effective  HSI  program  that  spans  the  entire  acquisition  Life  Cycle.  Without 
this  senior  level  buy-in,  the  program  will  falter  and  miss  its  goals. 

C.  AREAS  FOR  FURTHER  RESEARCH 

During  this  research,  other  areas  of  study  were  identified  that  would  strengthen 
the  practice  of  HSI.  These  topics  were  beyond  the  scope  of  study  for  this  research,  but  are 
presented  as  potential  research  topics  for  consideration. 
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Gap/comparative  analysis  of  the  current  HSI  documentation  for  all  other  DoD 
agencies,  including  other  services  (Air  Force,  Army,  Marine  Corps,  etc.) 

Whereas  this  thesis  focused  solely  on  the  Navy’s  use  of  HSI,  no  research  has  been 
conducted  on  the  gaps  that  lie  within  the  other  DoD  agencies’  and  services’ 
documentation  with  regard  to  HSI  in  the  IDAT&L  Life  Cycle  Management  Framework. 
The  same  model  used  in  this  thesis  can  be  used  as  a  baseline  for  other  service  policies. 
Recommendations  can  be  made  to  fill  gaps  in  these  HSI  documents  and  policies  as  well. 
These  gap  analyses  can  then  be  used  in  a  larger  comparative  analysis  to  ensure  that 
appropriate  changes  are  being  made  at  the  highest  level,  to  affect  all  DoD  agencies  and 
services. 

Analysis  of  the  trade-space  tools  used/needed  to  address  and  fill  the  gaps 
identified  throughout  the  IDAT&L  Life  Cycle  Management  Framework. 

In  order  to  effectively  close  the  gaps  identified  in  this  thesis,  an  analysis  of  trade- 
space  tools  should  be  done  based  on  the  needs  of  each  document.  As  seen  throughout  this 
thesis,  change  must  be  made  on  every  level  and  that  change  must  also  be  able  to  provide 
a  smooth  transition  between  document  levels.  To  effectively  accomplish  this,  trade-space 
tools  must  be  used  and/or  created.  These  same  tools  can  then  be  used  to  assess  the 
effectiveness  of  HSI. 

Analysis  of  the  effects  of  current  Navy  HSI  policies  and  procedures  on  overall 
system  procurement. 

As  mentioned  earlier,  due  to  current  documentation  and  policy  gaps,  it  is  rather 
difficult  to  trace  HSI  throughout  system  procurement.  An  analysis  of  the  effects  of 
current  HSI  policies  and  procedure  on  overall  system  procurement  should  be  done  to 
allow  a  thorough  review  to  occur  once  changes  have  been  made  to  policy  regarding  HSI. 
This  review  should  allow  top-level  officials,  as  well  as  all  personnel  involved  in  the  HSI 
process,  to  track  changes  and  gain  insight  for  areas  of  future  improvement. 

Comparative  cost  and  ejfectiveness  analysis  of  the  Navy ’s  HSI  support  sources. 
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Further  study  should  be  done  on  the  cost  effectiveness  of  alternative  approaches 
for  sourcing  and  employing  HSI  support  within  the  DoD  acquisition  framework.  Future 
research  should  look  at  the  cost  effectiveness  of  both  military  and  contracted  HSI  support 
services,  as  well  as  all  combinations  of  the  above.  The  end  goal  is  to  minimize  overall 
cost,  while  still  retaining  expert  skills  in  HSI  specialists. 
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APPENDIX 


THE  IDEAL  MODEL 


This  model  is  the  same  model  shown  throughout  the  thesis.  The  model  is  broken 
down  into  three  separate  diagrams  for  viewing  purposes  only.  Figure  27  shows  the  policy 
side  of  the  model.  Figure  28  shows  the  operational  side  of  the  model  through  TD.  Figure 
29  shows  the  operational  side  of  the  model  through  OS. 
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Figure  27.  The  Ideal  Model  (Policy  Side) 
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Figure  28.  The  Ideal  Model  (Operation  Side  through  TD) 
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1.2.16.1 


Figure  29.  The  Ideal  Model  (Operational  Side  through  OS) 
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